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PREFACE 


WORKSHOP  ON  APPLICATIONS  SYSTEMS  AND  REUSABILITY 

24-27  March  1986 

The  Department  of  Defense  Software  Technology  for- Adaptable  Reliable  Systems  (STARS) 
Project  is  holding  its  third  workshop  on  Applications  Systems  and  Reusability  24-27  March  1986 
at  the  Ramada  Inn,  Oxon  Hill,  MD. 

^  The  intent  of  this  workshop  series  is  to  seek  sources  of  information  and  expertise  in  the 
building  of  mission  critical  applications  software.  Reusable  part  specification,  building,  testing, 
maintaining  and  reutiU&ation  are  of  interest.  With  the  promulgation  of  Ada  as  a  single  High 
Order  Language  {HOL)  to  build  future  applications  within  the  three  DOD  services,  there  exist 
new  opportunities  of  reuse  of  software.  Reuse  could  reduce  software  system  development  time 
and  maintenance  costs,  and  improve  reliability.  The  intent  of  the  workshop  will  be  to  present 
and  discuss  summarized  material  on  the  following  issues: 


Specification/Design! 

*  <^(2)  Reusable  Component  Definitionj 
v-{3)  Validation  of  Software  Components^ 

-k(4)  Library  Experience^ 

4-(5)  Automated  Part  Composition^ 

^(6)  Logistics  of  Organizational  Reuse  of  Software  and  as  Government 
Furnished  Material,  and  Problems  Encountered  with  Data  Rights  and 
License  Arrangements,  and  User  Liability  Claims! 
i»-{7)  Encouraging  Deposits'^  fart— 

^{8)  Ada  Experience.  r~\ ^  ^  ^ _ _ 


VISE:  A  VISUAL  SOFTWARE  DEVELOPMENT 
ENVIRONMENT  SUPPORTING  REUSE 


Adarsh  K.  Arora 
James  C.  Ferrans 
Rob  Gordon 

Gould  Research  Center 
40  Gould  Center 
Rolling  Meadows,  IL  60008 

Objectives 


The  Visual  Software  Development  Environment  (VISE)  project  is  part  of  the  Visual  Program¬ 
ming  Project  at  Gould  Research  Center  (ARORA85).  The  overriding  objectives  of  the  Vise  Project 
are  to  decrease  software  development  time  and  improve  programmer  productivity  through  the  use  of 
workstation-based,  graphical  software  development  environments.  Since  software  development  is  a 
long  and  complex  process,  we  have  chosen  to  develop  tools  to  aid  in  the  detailed  design,  coding,  and 
debugging  stages  of  the  software  life-cycle. 

The  major  objectives  of  Vise  are  to: 

(1)  Build  an  integrated,  workstation-based  software  development  environment  that  allows  design, 
coding,  testing,  and  debugging  to  occur  in  parallel  without  forcing  the  user  to  make  expensive 
"context  switched1  between  the  editor,  the  compiler,  the  linkage  editor,  and  the  debugger; 

(2)  Exploit  advanced  user  interface  technology  to  make  programming  more  productive; 

(3)  Develop  rich  libraries  of  reusable  software  components  which  can  be  intelligently  searched  for 
incorporating  components  into  a  developing  program:  and 

(4)  Use  design  information  to  automatically  generate  target  language  code,  and  to  select  data  struc¬ 
tures  and  procedural  templates. 

The  accomplishment  of  these  goals  would  represent  a  considerable  improvement  in  programmer 
productivity  and  would  reduce  the  duration  of  the  software  life-cycle. 


Description  of  Project 

Current  software  development  tools 
offer  little  help  in  mapping  the  initial  abstract 
solution  of  a  problem  into  a  target  language 
program.  They  generally  address  isolated 
stages  of  the  life-cycle.  For  example,  pro¬ 
gram  design  languages  (e.g.,  (Teic77)  are 
used  to  specify  a  high-level  description  of  a 
program,  while  syntax-directed  editors  ease 
the  coding  task.  No  general  tools  exist  that 
assist  in  the  transition  from  a  high-level 
problem  description  to  target  language  source 
code. 

The  first  rough  draft  of  a  program  is 
typically  an  informal,  structured-English 


description.  Subsequent  versions  refine  this 
description  to  successively  lower  and  more 
precise  decompositions  of  the  problem  until 
the  target  language  is  reached.  Vise  captures 
data  types  and  procedural  information  from 
the  tater  design  stages  and  uses  it  to  generate 
the  target  language  code  directly.  To  support 
this.  Vise  allows  a  program  to  contain 
pseudo-code  statements  called  design  notes 
as  well  as  normal  target  language  text.  The 
programmer  can  select  a  design  note  and  ask 
the  system  to  refine  it  into  target  language 
code.  After  this  is  done,  the  refinement  code 
is  inserted  and  the  design  note  becomes  a 
comment  introducing  the  code.  Refinement 
is  driven  by  information  kept  in  one  or  more 


Software  Components  Libraries  (SCLs).  SCL 
organization  and  refinement  is  discussed  in  a 
subsequent  section. 

Vise  will  also  address  testing  and 
debugging.  Graphical  data  structure  display 
and  animation  and  control  flow  tracing  will  be 
used  to  enhance  the  programmer’s  ability  to 
monitor  program  behavior.  Trace  and 
single-step  facilities  will  provide  the  capability 
of  viewing  how  each  program  statement 
affects  a  particular  data  object. 

Finally,  a  long  term  goal  of  the  Vise 
project  is  to  incorporate  an  expert  system  to 
aid  in  automatic  data  structure  selection. 
After  asking  the  user  about  usage  patterns 
and  access  requirements,  the  assistant  wilt 
suggest  appropriate  data  types  and  give  the 
rational  behind  their  selection. 


Technical  Approach 

Vise  is  being  developed  on  Sun  work¬ 
stations  using  UNIX,  C,  and  Objective  C. 
With  the  decreasing  cost  of  networked, 
single-user  workstations,  soon  it  will  be  prac¬ 
tical  to  equip  every  programmer  with  one. 
The  graphics  capabilities  of  these  worksta¬ 
tions  make  them  a  logical  choice  for  hosting 
a  visual  development  environment  We  are 
initially  supporting  the  C  language,  but  our 
technology  is  general  and  can  be  easily 
applied  to  ADA,  FORTRAN,  and  other 
languages. 

The  Task  Environment  Manager 
(TEM)  is  the  control  and  coordination  layer 
packaging  ail  Vise  tools.  It  is  responsible  for 
tracking  the  environment  of  a  programming 
task:  which  source  files  belong  to  it,  which 
libraries  it  references,  etc.  It  is  used  to 
import  existing  target  language  files  into  the 
system  and  export  files  out  of  Vise.  In  the  C 
language  implementation,  the  TEM  export 
facility  generates  the  "make”  file  used  to  build 
the  task  with  conventional  UNIX  develop¬ 
ment  tools. 

A  syntax-directed  editor  and  an  incre¬ 
mental  compiler  form  the  foundation  of  Vise. 
The  programmer  can  have  multiple  edit  win¬ 
dows  open  simultaneously  on  different  source 
files,  and  every  change  he  makes  is  compiled 


and  checked  as  he  makes  it.  The  incremental 
compiler  keeps  an  internal  abstract  syntax 
tree  of  the  program  in  executable  form.  As 
in  PECAN  (Reis84),  we  intend  to  support 
geographical  display  and  editing  of  programs 
(e.g.,  via  flow  charts  and  Nassi- 
Schneidermann  diagrams)  as  well  as  textual 
editing.  The  target-  language  syntax  is  aug¬ 
mented  to  accep*  design  notes  in  arbitrary 
natural  language. 

The  Animator/Debugger  is  an  inter¬ 
preter  that  walks  the  abstract  syntax  tree  and 
executes  the  program.  It  supports  the  typical 
facilities  of  today’s  symbolic  debuggers  (e.g., 
control  flow  tracing,  breakpoints,  watch- 
points,  stepping)  as  well  as  higher-level 
graphical  display  of  data  structures.  Control 
flow  animation  is  done  through  the  program 
editing  views,  as  in  PECAN. 

Vise  also  contains  a  help  facility  and  an 
Agenda  Manager  (AM).  The  AM  is  used  to 
keep  agendas  of  pending  items  that  need  to 
be  done.  For  instance,  if  the  editor  finds  a 
syntax  error,  this  error  is  automatically  added 
to  an  agenda  for  that  source  file,  and 
automatically  removed  when  it  is  fixed.  The 
user  can  create  his  own  agendas  of  re¬ 
minders. 

The  final  component  of  Vise  is  the 
Software  Component  Library  Manager 
(SCLM).  We  describe  its  organization  and 
how  it  supports  design  note  refinement  in  the 
next  section. 

Software  Component  Library  Manager 

Software  Component  Libraries  are  col¬ 
lections  of  reusable  software  modules  along 
with  documentation  and  other  supporting 
information.  The  SCLM  manages  these 
libraries  and  supports  browsing  and  updating 
operations.  Libraries  may  be  organized  in 
any  manner,  both  topically  and  organization¬ 
ally,  and  may  be  owned  by  anyone. 

The  major  type  of  component  in  an 
SCL  is  the  Abstract  Data  Type  (ADT).  This 
corresponds  closely  to  an  ADA  package. 
Support  also  exists  for  generic  ADTs,  which 
correspond  to  ADA  generic  packages.  ADTs 
may  be  derived  from  generic  ADTs,  and  the 
user  may  create  instances  of  ADTs  in  a  pro¬ 
cess  called  instantiation. 


SCLs  also  contain  independent  func¬ 
tions  (those  that  do  not  pertain  to  an  ADT) 
and  code  templates,  along  with  a  hierarchical 
index  to  them.  Documentation,  sources, 
objects,  and  preprocessor  "include"  files  are 
also  available  for  use  or  perusal  They  also 
contain  linguistic  information  needed  in 
design  note  recognition. 

When  a  user  picks  out  a  design  note 
and  asks  the  editor  to  refine  it  into  target 
language  code,  the  editor  passes  the  note  to 
the  SCLM.  The  SCLM  uses  a  simple  key¬ 
word  recognition  scheme  to  search  each  SCL 
for  matching  actions,  and  the  user  selects 
which  one  looks  most  appropriate  if  more 
than  one  action  was  matched.  The  action 
refers  to  some  independent  function,  code 
template,  or  ADT  operation  function,  and 
the  appropriate  function  call  or  other  target 
language  code  is  inserted  into  the  program  in 
place  of  the  design  note.  The  note  becomes 
a  comment  to  the  new  code. 

The  user  can  make  refinement  very 
loose  (only  one  word  in  the  design  note 
matches  a  word  in  an  action  template)  or 
very  restrictive  (the  design  note  must  match 
the  action  template  semantics  exactly). 
When  the  user  picks  the  desired  action, 
linguistic  analysis  is  used  to  extract  informa¬ 
tion  from  the  design  note  and  insert  it  into 
slots  in  the  generated  code. 

STARS  Program  Relationship 

The  Vise  Project  addresses  two  major 
goals  of  the  STARS  program:  It  provides 
software  life-cycle  support  as  desired  by  the 
Software  Engineering  Environment  (SEE) 
portion  of  STARS,  and  also  meets  the 
requirements  for  portable  and  reusable 
software  parts  as  specified  by  the  Applications 
segment. 

An  ADT-based  library  architecture  is 
well-suited  to  the  goal  of  similar  applications, 
allows  parametric  refinement  of  parts,  and 
supports  parts  composition.  Libraries  can  run 
the  gamut  between  genetically  useful  and 
application-  or  user-specific.  Software 
developers  working  on  an  application  (e.g., 
signal  processing,  avionics,  missile  control, 
navigation)  often  use  a  particular  model 
when  designing  systems.  The  availability  of 
software  parts  corresponding  to  the  model 
increases  productivity. 

The  Visual  Programming  Project  also 
has  under  its  umbrella  a  domain  specific 


application  of  Vise  technology.  Gould 
Research  Center  has  recently  awarded  a  one 
million  dollar  contract  from  LABCOM  to 
develop  a  visual  VHDL  Design  Workbench 
for  hardware  designers.  With  the  DoD 
requirement  that  all  VHSIC  chips  be  specified 
using  VHDL,  an  Ada-like  hardware  design 
language,  the  DoD  has  initiated  work  on  con¬ 
structing  a  development  environment  for  the 
VHDL  designer.  The  VHDL  Workbench 
provides  a  graphical  environment  for  the 
specification  of  hardware  components  and  the 
automatic  generation  of  portions  of  VHDL 
through  interaction  with  this  environment. 

Current  Status 

The  development  of  Vise  has  been 
divided  into  three  phases.  In  Phase  I  we  are 
devising  the  core  system:  the  text  editor,  the 
incremental  compiler,  the  Software  Com¬ 
ponent  Library  Manager,  design  note 
refinement  the  Task  Manager,  and  the 
Agenda  Manager.  We  have  six  people  work¬ 
ing  on  the  project  and  expect  to  be  finished 
by  the  summer  of  1986. 

In  Phase  II  we  intend  to  enhance  the 
Phase  I  components  and  add  the  following 
capabilities:  graphical  program  display  and 
editing  methods,  new  SCLM  capabilities, 
additional  SCLs,  and  the  visual 
Animator/ Debugger.  This  is  scheduled  for 
completion  in  1987. 

The  last  phase  will  explore  expert  sys¬ 
tems  technology  for  data  structure  selection 
and  the  use  of  better  natural  language  recog¬ 
nition  techniques  in  design  note  recognition. 
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Abstract 

In  the  software  engineering  environment  of  the  1980’s,  the  reusability  of  software  is  expected  to 
be  a  prime  factor  influencing  the  productivity  of  software  development  organizations.  This  paper 
discusses  a  prototype  system  developed  at  Planning  Research  Corporation  used  to  demonstrate  the 


feasibility  of  determining  the  reusability  of  software 

Introduction 

Under  constant  pressure  to  produce 
computerized  systems  of  ever  increasing  size 
and  complexity,  most  large  organizations 
engaged  in  software  development  are  forced 
to  continuously  find  ways  to  improve  produc¬ 
tivity.  In  today’s  environment,  a  software 
development  organization  of  any  size  usually 
controls  thousands  upon  thousands  of  lines 
of  diverse  software,  most  of  which  was  not 
explicitly  designed  for  reuse.  Significant  time 
and  cost  savings  can  be  realized  in  most 
organizations  if  an  effective  means  to  reuse 
this  software  can  be  developed.  Clearly, 
some  pieces  of  this  software  can,  in  practice, 
be  reused  in  applications  and  systems  not 
originally  envisioned  by  their  designers.  The 
heart  of  the  problem  lies  in  finding  an 
efficient  way  to  identify  and  select  the  poten¬ 
tially  reusable  software. 

The  Prototype  Project 

In  order  to  gain  a  better  understanding 
of  how  to  exploit  the  potential  of  this  body  of 
software.  Planning  Research  Corporation 
decided  to  pursue  the  development  of  a  pro¬ 
totype  system  to  qualify  software  for  use  in  a 
reusable  software  inventory  system.  During 
the  development  of  the  prototype,  it  was 


which  was  not  originally  designed  for  reuse. 

shown  through  internal  projects  within  the 
Productivity  Products  Group  at  Planning 
Research  Corporation,  that  systems  on  the 
order  of  30K+  lines  of  code  can  achieve  re¬ 
usability  rates  in  excess  of  60%,  even  if  the 
reused  software  was  not  originally  designed 
and  implemented  for  reuse.  Identifying  and 
extracting  the  reused  pieces  of  software  from 
their  original  libraries  was  a  labor  intensive 
and  time-consuming  process  which  is 
intended  to  be  automated  by  the  prototype. 

The  development  of  the  prototype 
qualification  system  has  also  demonstrated 
that  the  benefits  of  large-scale  reuse  can  be 
magnified  by  integrating  the  software  reuse 
qualification  process  into  a  SEE  (software 
engineering  environment).  The  interactive 
screens,  user  commands,  flow  of  data,  imple¬ 
mentation  techniques,  and  database  storage 
techniques  used  in  the  prototype  system  are, 
by  design,  consistent  with  Planning  Research 
Corporation’s  APCE  (Automated  Product 
Control  Environment)  product,  the 
corporation’s  standard  software  engineering 
environment.  Extending  the  APCE  to 
include  an  automated  reusable  software 
qualification  process  is  a  simple  task  which 
allows  software  reuse  to  occur  in  an  orga¬ 
nized  and  disciplined  fashion. 


At  the  beginning  of  the  prototype 
development  project,  it  was  decided  that  the 
prototype  should  exhibit  the  following 
characteristics: 

o  It  should  be  able  to  qualify  software  not 
explicitly  designed  for  reuse,  as  well  as 
software  explicitly  designed  for  reuse. 

o  It  should  not  be  tied  to  a  specific  computer 
language;  it  should  be  able  to  accept  "raw” 
input  software  written  in  many  different 
source  languages.  Although  Ada  is  without  a 
doubt  the  language  of  choice  for  future 
development,  there  is  a  large  body  of 
software  written  in  other  languages  that  can 
be  effectively  reused. 

o  The  qualification  process  should  be  adapt¬ 
able  so  that  the  qualification  criteria  can  be 
adjusted  as  more  is  learned  about  the  charac¬ 
teristics  of  reusable  software. 

o  Software  accepted  into  the  reusable  inven¬ 
tory  by  the  qualification  process  should  be 
classified  and  stored  so  that  it  can  later  be 
retrieved  by  its  attributes,  and  it  must  be 
stored  in  a  manner  compatible  and  consistent 
with  an  organization’s  SEE  or  software  fac¬ 
tory  system. 

The  prototype  design  consists  of  three 
major  subsystems:  the  Analyzer  Subsystem, 
the  Qualification  Subsystem,  and  the  Interro¬ 
gation  Subsystem.  Data  flows  through  the 
prototype  from  the  Analyzer  Subsystem, 
where  "raw”  input  software  is  inspected,  to 
the  Qualification  Subsystem,  which  makes 
decisions  based  upon  the  analysis  of  the  "raw" 
input  software,  to  the  Interrogation  Subsys¬ 
tem,  which  is  used  to  retrieve  selected  pieces 
of  software  stored  in  the  reusable  inventory. 

The  Analyzer  Subsystem 

A  block  diagram  of  the  Analyzer  Sub¬ 
system  is  presented  in  Figure  1.  "Raw”  input 
software  can  be  analyzed  whether  or  not  it 
was  explicitly  designed  for  reuse.  The 
Analyzer  Subsystem  determines  the  source 
language  of  the  "raw"  input  software  and, 
through  the  use  of  a  grammar  for  the  source 
language,  develops  metric  data  from  the 
input  If  the  "raw"  input  is  a  large  piece  of 
software,  for  example  an  entire  application 
program,  the  Analyzer  Subsystem  breaks 
down  the  input  into  smaller  pieces  and 


records  the  relationships  between  the  pieces. 

Because  the  Analyzer  Subsystem  is  con¬ 
structed  so  that  it  is  driven  by  a  specific 
grammar  file  for  the  "raw"  input  software,  it 
is  flexible  and  can  accommodate  a  wide 
variety  of  source  languages.  The  prototype 
system  has  been  demonstrated  to  be  capable 
of  processing  both  Ada  PDL  and  PASCAL 
input  software.  The  estimated  level  of  effort 
required  to  extend  the  language  processing 
capabilities  of  the  prototype  is  on  the  order  of 
a  few  man- weeks. 

The  Qualification  Subsystem 

At  the  time  the  prototype  was 
developed,  it  was  felt  that  the  decision  mak¬ 
ing  process  required  to  qualify  "raw"  input 
software  for  reuse  was  not  fully  understood. 
Casting  the  decision  making  process  into  a 
complex,  and  difficult  to  change  program  was 
not  an  acceptable  or  practical  approach  to  the 
problem.  It  was  obvious  that  the  prototype 
had  to  include  A1  techniques  to  avoid  re¬ 
compiling  or  re-linking  major  pieces  of  the 
prototype  for  each  change  to  the  qualification 
decision  making  process. 

Figure  2  is  an  overview  of  the  flow  of 
data  through  the  prototype’s  Qualification 
Subsystem.  Metric  data,  information  about 
the  relationships  found  in  the  "raw”  input 
software,  and  some  user-supplied  text  data 
are  sent  through  a  qualification  process  con¬ 
trolled  oy  a  Planning  Research  Corporation 
developed  A1  module  called  GEM  (Generic 
Expert  Module) . 

GEM  is  used  to  apply  a  set  of 
qualification  rules  against  the  metric  and  rela¬ 
tional  data  supplied  by  the  Analyzer  Subsys¬ 
tem.  GEM  determines  whether  a  piece  of 
"raw”  input  software  is  qualified  to  be  stored 
in  the  reusable  software  inventory.  As  the 
dynamics  of  qualifying  "raw"  input  software 
come  into  better  focus,  the  rule  base  can  be 
easily  modified  with  re-compiling  or  re¬ 
linking  any  software  in  the  entire  prototype 
system. 

Rules  on  the  rule  base  file  are  written 
in  straight-forward  English-like  constructs, 
and  are  interpreted  dynamically  at  run-time 
by  the  GEM.AI  module.  GEM  has  powerful 
logical  operators  that  allow  rules  to  be 


developed  that  can  accommodate  a  wide 
range  of  input  software  sizes  and  source 
languages.  In  addition  to  logical  operators, 
GEM  has  computational  features  which  allow 
a  rule  base  to  be  developed  that  can  calculate 
arbitrarily  defined  values  such  as  portability 
factors,  logical  complexity  factors,  and  inter¬ 
face  complexity  factors. 

As  an  additional  means  to  cope  with  the 
dynamics  of  its  decision  making  process,  the 
Qualification  Subsystem  has  interactive 
screens  which  allow  a  user  of  the  prototype 
to  review  decisions  made  as  a  result  of  apply¬ 
ing  the  rule  base  to  the  Analyzer  Subsystem’s 
data.  Numerical  and  relational  data  produced 
by  the  Analyzer  Subsystem  relative  to  any 
particular  piece  of  "raw"  input  software  can  be 
displayed  on  command,  as  well  as 
qualification  decisions  made  by  GEM.  A 
simple  command  from  an  interactive  screen 
can  be  used  to  override  any  automated  deci¬ 
sion. 

As  pieces  of  "raw"  input  software  are 
accepted  by  the  Qualification  Subsystem,  they 
are  stored  in  the  reusable  inventory  along 
with  numerical  and  relational  data  produced 
by  the  Analyzer  Subsystem.  The  Interroga¬ 
tion  Subsystem  of  the  prototype  can  be  used 
to  select  the  stored  pieces  of  software  based 
upon  various  attributes,  and  can  be  used  to 
display  numerical  and  relational  data. 

Reuse  and  Development  Standards 

An  unexpected  use  of  the  prototype 
system  surfaced  after  its  development.  It  was 


realized  that  the  prototype  system’s  rule 
based  could  easily  be  modified  to  enable  the 
prototype  to  be  used  as  a  fast  and  highly 
efficient  IV&V  tool.  With  a  rule  base  that 
reflects  an  organization’s  fundamental 
software  development  standards  (for  exam¬ 
ple,  number  of  lines  per  module,  amount  of 
comments,  overall  complexity  per  module, 
etc.)  the  prototype  system  could  be  employed 
to  automate  first  level  software  inspections  or 
walkthroughs  which  have  traditionally  been 
performed  manually. 

Conclusions 

A  number  of  things  were  learned  dur¬ 
ing  the  development  of  the  prototype. 

o  Reusability  in  excess  of  60%  can  be 
achieved,  even  when  the  reused  software  was 
not  intended  for  reuse. 

o  Large-scale  software  use  is  best  carried  out 
as  an  integrated  function  of  a  SEE. 

o  A  reusability  system  need  not  be  tied  to  a 
specific  source  language 

o  Some  of  the  problems  of  automating 
software  development  standards  inspection 
and  identifying  reusable  software  are  similar. 

o  Finally,  A1  tools  and  techniques  can  be 
applied  in  harmony  with  conventional 
software  to  attack  ill-defined  and  complex 
problems  frequently  encountered  in  the 
development  of  automated  software 
engineering  environment  systems. 


Figure  2.  Qualification  Subsystem  Block  Diagram 
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INFORMATION  THEORY  AND  SOFTWARE  REUSE 


Rodney  M.  Bond 

ARINC  Research  Corporation 
2SS1  Riva  Road 
Annapolis,  Maryland  21401 

Abstract 


In  this  paoer  a  paradigm  for  so/hvare  reusability  currently  being  researched  is  reviewed.  A  gen¬ 
eral  discussion  of  information  theory  is  presented  followed  by  a  short  discussion  of  software  testing 
concepts.  Dependency  analysis  is  then  presented  as  a  possible  approach  to  unifying  these  two  fields. 
Possible  paradigms  for  dependency  analysis  are  then  proposed  along  with  some  anticipated  problems. 
Finally,  a  summary  is  given  which  identifies  related  fields  to  which  this  research  might  be  applied. 


Information  Theory 

Information  theory  research  started  in 
the  1920’s  in  support  of  a  need  to  model 
communication  systems.  The  basic 
mathematical  concepts  used  today  were 
derived  by  the  late  1940’s  by  mathematicians 
including  N.  Wiener  and  C.  Shannon.  Infor¬ 
mation  theory  proposes  to  answer  a  question 
attributed  to  U.S.  political  scientist  Harold  D. 
LaswelKl),  "Who  says  what  to  whom  with 
what  effect?"  In  attempting  to  answer  this 
question,  one  activity  included  the  develop¬ 
ment  of  a  quantitative  theory  of  information 
measure(2).  Though  not  the  only  model, 
nor  a  universally  accepted  model,  one  theory 
measures  "usefulness"  of  information  based 
on  three  metrics:  entropy,  self-information, 
and  probability.  Entropy,  H(«),  in  informa¬ 
tion  theory  is  a  measure  of  the  uncertainty 
associated  with  a  message  source.  Self¬ 
information,  I( •)  is  a  measure  of  the  infor¬ 
mation  contained  in  a  particular  variable,  x; 
and  probability  is  a  measure  of  the  chance 
occurrence  of  the  i(th)  variable,  p(Xj).  These 
three  measures  are  related  by  the  equation: 

Etl(Xj)]  -  H(X)  - 
Ip(Xi)I(Xj)  -  -Ip(Xj)  log  (pfXj)) 

where  the  summations  are  over  "M‘  unique 
symbols,  E[*i  is  the  expected  value  lunction, 
and  X  is  a  random  variable.  When  M  ~  2, 
where  the  symbols  might  be  represented  by 
[0,1],  or  [true,falsel,  or  some  other  mutually 


exclusive  and  exhaustive  pair  of  values,  the 
equation  has  a  maroman  ximum  value  at 
pfjCj)  0.5.  Hence  the  maximum  entropy, 
or  unknown  information,  for  a  binary  alpha¬ 
bet  system  occurs  when  there  is  an  equal 
chance  of  something  happening,  e.g.  being 
true  or  false. 

Software  Testing 

During  the  fault  isolation  process  of 
software  testing  an  attempt  is  being  made  to 
obtain  information  through  tests,  specifically 
the  identification  of  a  "faulty1-  component. 
Obviously  the  meaning,  amount,  and  scope 
of  the  available  information  has  to  be  con¬ 
sidered  in  order  to  achieve  identification.  If 
we  limit  ourselves  to  a  binary  scope  of  infor¬ 
mation,  such  that  there  are  only  two  possible 
values  for  the  information  sought,  i.e.  an  M 
-  2  alphabet,  we  may  arbitrarily  choose  the 
alphabet  to  consist  of  the  symbols 
[good, bad).  We  can  now  associate  a  meaning 
to  these  symbols.  In  this  paper  "good"  and 
"bad"  will  be  used  to  mean  the  result(s)  of  a 
test,  with  no  other  results  possible.  Now  that 
the  meaning  and  scope  of  the  information  to 
be  gathered  has  been  defined,  the  amount  of 
the  information  to  be  gained  from  a  test 
must  be  determined. 

There  is  a  significant  variation  in  the 
amount  of  information  that  may  be  acquired 
from  a  test.  Suppose  that  there  is  a  software 
program  with  "X"  inputs,  "Y"  modules,  and 
"Z"  outputs  as  components.  We  wili  also 
assume  that  the  inputs  must  somehow  be 
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generated,  and  the  outputs  evaluated.  If  ail 
inputs,  modules,  and  outputs  were  intercon¬ 
nected,  an  exhaustive  test  set  would  include 
on  an  order  of  magnitude  X*Y*Z*  tests.  If 
we  were  to  analyze  this  system  to  isolate  an 
error,  and  assuming  a  single  fault,  we  might 
start  by  testing  an  input.  If  the  test  was 
good,  we  would  have  very  little  information 
gain,  only  the  knowledge  that  the  one  input 
was  good.  However,  if  the  test  was  bad  we 
would  have  isolated  the  error.  Conversely,  a 
good  output  test  would  tell  us  that  ail  com¬ 
ponents  feeding  the  output  were  good, 
whereas  a  bad  output  test  would  tell  us  only 
that  one  of  the  components  feeding  the  out¬ 
put  were  bad.  The  information  gain  from  the 
good  output  test  is  of  more  value  since  it 
identifies  the  status  of  more  of  the  com¬ 
ponents. 

Thus  it  appears  that  information  gain  is 
maximized  with  bad  tests  near  the  input  and 
good  test  near  the  output.  However,  since 
the  outcome  of  a  test  cannot  be  ascertained 
prior  to  the  test,  current  strategies  for  deter¬ 
mining  the  order  in  which  the  tests  are  to  be 
performed  include  random  selection,  from 
outputs  toward  inputs,  and  from  inputs 
toward  outputs.  Information  theory  can  be 
used  to  generate  a  more  reasonable  strategy. 
From  information  theory  we  know  that  the 
maximum  entropy  occurs  in  our  binary  alpha¬ 
bet  when  the  probabilities  of  "good"  and 
"bad"  are  equal.  Selection  of  the  test  with 
maximum  entropy  will  provide  an  answer  to 
the  most  "unknown"  information  possible 
from  a  single  test.  Hence  our  strategy  should 
be  to  choose  a  test  that  gives  the  most  nearly 
equal  information  gain,  regardless  of  the  out¬ 
come,  eliminating  the  most  entropy  from  the 
analysis.  It  can  be  shown  that  this  strategy 
approaches  the  theoretical  limit  of  eliminating 
half  of  the  components  from  consideration 
with  each  test(3). 

Dependency  Analysis 

In  order  to  choose  the  test  with  max¬ 
imum  entropy  some  algorithm  for  the  assign¬ 
ment  of  information  gain  must  be  es¬ 
tablished.  One  approach  is  a  form  of  depen¬ 
dency  modeling.  For  simplicity  of  example, 
assume  we  have  four  boolean  variables:  Bl, 
B2,  B3,  and  B4;  and  three  software  modules: 
Ml,  M2,  and  M3  related  by  the  following 


program  segment. 

Call  M2  with  Bl  returning  B3 

Routine  M2 
Call  M3  returning  B2 
Call  M4  with  B3  returning  B4 


The  following  data  and  control  depen¬ 
dencies  can  be  identified.  Variable  B4 
depends  on  module  M4  and  variable  B3. 
Variable  B3  depends  on  module  M2  and  vari¬ 
able  Bl.  These  are  called  first  order  depen¬ 
dencies.  By  inference  through  variable  B3, 
we  can  also  reason  that  B4  depends  on 
module  M2  and  variable  Bl.  This  is  called  a 
higher  order  dependency.  Through  identify¬ 
ing  all  dependencies  and  applying  a  weighting 
algorithm,  a  figure  fer  the  information 
entropy  value  of  each  test,  here  represented 
by  a  boolean  variable,  can  be  determined. 
This  would  then  provide  values  of  entropy 
for  our  information  theoretic  approach  to 
error  analysis.  For  complex  software  topolo¬ 
gies,  computer  processing  will  be  required  for 
determination  of  all  higher  order  dependen¬ 
cies.  The  initial  requirement  would  be  the 
identification  of  first  order  dependencies, 
tests,  and  modules.  This  could  easily  be 
done  manually,  or  possibly  with  a  simple 
tool.  The  data  may  even  exist  already  for 
systems  developed  with  a  structured  analysis 
and  design  approach. 

Paradigm  Concepts 

Now  that  we  have  identified  the  theory, 
one  area  of  application,  and  an  implementa¬ 
tion  approach  to  using  information  theoretics, 
the  next  step  is  to  relate  the  presented 
material  to  the  area  of  software  reusability. 
The  potential  for  application  covers  a  wide 
spectrum  of  possibilities. 

Reuse  Metrics 

If  we  just  performed  a  dependency 
analysis  of  a  software  program  on  any  one  of 
several  possible  dependency  relationships 
such  as  shared  data,  execution  control,  inter¬ 
faces,  scheduling,  etc.;  the  analysis  could  be 
used  to  generate  a  relative  metric  associated 
with  that  characteristic.  The  metric  is  rela- 


tive  because  it  probably  would  have  no  abso¬ 
lute  meaning,  but  would  be  very  useful  in 
characterizing  the  program.  One  program 
might  have  a  shared  data  metric  very  high 
with  respect  to  another  program,  both  of 
which  could  be  used  as  a  reusable  component 
within  some  other  program. 

Depending  on  the  type  and  quantity  of 
modifications  required,  the  program  with  less 
shared  data  dependencies  may  prove  easier  to 
modify.  Similar  arguments  could  be  gen¬ 
erated  for  other  types  of  metrics  that  might 
be  generated. 

Context-Free-Comparisons 

The  set  of  values  which  represent  the 
dependencies  within  a  program  may  also 
represent  a  fingerprint  of  that  system.  This 
fingerprint  in  general  would  be  free  of  any 
context  description  of  the  program  such  as 
language  of  implementation,  host  computer, 
or  field  of  application.  Comparisons  of  these 
sets  of  data  might  be  useful  in  identifying 
reusable  but  abstract  concepts  such  as  the 
requirements  or  design  of  a  program. 

E3  Methodology 

Dependency  analysis  can  be  seen  to 
have  direct  applicability  to  a  Form-Fit- 
Function  (F3)  type  of  methodology (4).  This 
is  the  use  of  "standard  characteristics"  for  the 
specification  of  requirements.  The  charac¬ 
teristics  could  include  any  aiscussed,  or  even 
more  complex  characteristics  based  on 
advanced  algorithms  for  determining  metrics 
such  as  "coupling”  or  "cohesion."  This  is  not 
equivalent  to  using  a  "black-box"  description 
of  a  program  because  the  dependency  model 
includes  the  internal  workings  as  well  as  the 
interfaces.  To  be  a  complete  methodology, 
the  "approach"  not  only  would  identify  the 
best  fitting  software  for  reuse  by  these 
characteristics,  possibly  from  a  library  of 
software;  but  would  also  provide  insight  into 
how  or  where  modifications  should  be  made 
in  order  to  make  two  programs  compatible. 

Anticipated  Problems 

The  concepts  described  in  this  paper  are 
currently  being  applied  by  ARINC  Research 
Corporation  in  the  field  of  hardware  system 


testing  (5).  Research  into  the  applicability  of 
the  methods  for  software  testing  is  currently 
being  funded  internally.  Some  of  the  key 
issues  to  be  addressed  by  this  research  are:  1 ) 
the  identification  of  what  dependencies  can 
be  generated,  2)  the  applicability  of  these 
dependencies  to  software  related  problems 
such  as  fault  isolation,  reusability,  reliability, 
test  development,  fault  tolerance,  and  secu¬ 
rity,  3)  how  the  data  acquisition  for  depen¬ 
dency  analysis  can  be  gathered,  and  4)  how 
can  the  problem  be  structured  to  minimize 
processing  requirements. 

Summary 

The  concepts  of  information  entropy 
and  self-information  combined  with  probabil¬ 
ity  have  been  applied  to  the  field  of  hardware 
testing  with  considerable  success.  Research  is 
being  conducted  into  the  extension  of  this 
work  to  the  field  of  software  testing.  There 
is  a  potential  for  application  of  the  basic  con¬ 
cepts  to  many  other  fields  of  software  and 
systems  analysis.  The  primary  consideration 
in  our  approach  is  that  the  problem  must  be 
formable  as  a  dependency  model. 
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‘Who  says  what  to  whom  with  what  effect?' 


C.  E.  Shannon 


Quantitative  Theory  of  Information  Measure 


Not  the  only  model 


Not  universally  accepted 


Uses  three  metrics 


Entropy  {H} 


Self-information  {1} 


Probability  {p} 


M  M 

H(X)=E[I(x1')]=2p(Xj>I(X|)=-2p(x|Wog[p(X|)] 

i-1  i=*1 

••  E  s  expected  value  function 
••Ms  number  of  unique  symbols 
••  X  s  random  variable 
For  binary  system  {M=2} 

••  10,1 }  {true,false}  {nothing, something} 
••  Mutually  exclusive  &  exhaustive 

••  p(xj)=0.5=*H(X)max 

••  Equal  chance  =*  maximum  entropy 


Information 


Let  M=2,  X={result  of  test},  xp'good',  X2=’bad' 


•  Information  gain  maximuzed 
••  good  test  near  input 
••  bad  test  near  output 

•  Test  strategies 

••  No  prior  knowledge  of  test  outcome 
••  Random 
••  Directed 
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Select  "equal  information  gain”  test 


Answers  most  "unknowns’ 


Approaches  half-interval  limit 
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1st  order  dependencies 
Higher  order  dependencies  &  automation 
Weight  to  get  Information  Entropy  test  value 
Possibly  use  existing  dependency  data 


Reuse  metrics 


•*  Data 
•*  Control  ... 

••  'Characterizing"  metrics 
Context-free  comparisons 
••  'Fingerprint' 


••  Applicable  to  abstractions 


•  methodology 

••  Use  of  standard  characteristics 
••  Not ’black  box' 

••  ID  best  fitting  software  from  library 
••  Provide  modification  data  ... 
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Dependencies? 

Dependency  applicability  to  software  problems 
Data  acquisition 

Minimize  processing  requirements 

Is  the  hardware/software  translation  viable? 


WHY  PROGRAMS  BUILT  FROM  REUSABLE  SOFTWARE 
SHOULD  BE  SINGLE  PARADIGM 
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Abstract 


This  paper  argues  that  it  becomes  possible  and  economical  to  reuse  software  only  when  all  the 
reusable  parts  exhibit  a  single  paradigm  and  suggests  that  object-orientation  is  one  recommendable 
paradigm. 


Keywords :  Ada,  reusable  software  parts,  object-oriented  programming. 


This  research  was  supported  in  part  by  the  Office  of  Naval  Research  under  contract  No.  N00014-85- 
C-0666. 


1.  INTRODUCTION 

Honeywell  Computer  Sciences  Center’s 
RaPIER  (Rapid  Prototyping  to  Investigate 
End-user  Requirements)  project  is  currently 
working  on  a  methodology  and  automated 
support  for  constructing  and  using  prototypes 
to  investigate  end-user  requirements.  Tradi¬ 
tional  requirements  definition  methods  con¬ 
sistently  fail  to  produce  requirements  from 
which  satisfactory  systems  can  be  designed 
and  built  [ZAVE85].  We  believe  that  rapidly 
built  prototypes  which  model  critical  systems 
requirements  can  lead  to  early  consensus  on 
requirements  that  are  acceptable  to  customers 
and  feasible  to  implement. 

The  RaPIER  approach  [CSC86]  is  to 
build  prototypes  from  reusable  Ada  software 
parts  stored  in  a  software  database,  and  to 
express  them  in  a  very  high  level  language 
that  specifies  how  the  parts  are  tailored  and 
interconnected  to  form  a  complete  prototype. 
The  RaPIER  project  has  the  opportunity  to 
test  the  feasibility  of  this  approach  with  non¬ 
product  software,  in  a  non-time-critical 
milieu  and  to  test  different  styles  of 
implementating  reusable  part  in  this  less 
demanding  milieu.  We  intend  to  experiment 
with  the  approach  using  Ada  on  the  Symbol¬ 
ics  and  a  very  high  level  prototype  system 


description  language  (PSDL)  developed  by 
International  Software  Systems  Inc.(l)  We 
chose  the  Symbolics(TM),  a  Lisp  machine 
with  support  for  dynamic  linking,  because 
prototyping  demands  a  great  deal  of  program 
modification  at  run-time.  We  expect  their 
Ada  compiler,  which  we  will  be  receiving 
shortly,  to  exploit  these  facilities.  We  have 
already  built  two  example  prototypes  using 
Lisp  flavors  as  implemented  on  the  Symbol¬ 
ics. 

This  paper  is  organized  as  follows:  Sec¬ 
tion  2  discusses  three  assumptions  about 
reusing  software  that  underlie  the  recommen¬ 
dation  of  single- paradigm  programs.  Section 
3  presents  the  reuse  process  and  a  critical 
requirement  for  reusable  software.  Section  4 
discusses  how  single-paradigm  programs  facil¬ 
itate  the  reuse  process  and  support  the  critical 
requirements.  Section  5  recommends 
object-orientation  as  a  suitable  paradigm. 
Section  6  discusses  future  work. 


2.  ASSUMPTIONS 

Our  experience  in  building  prototypes 
by  reusing  Lisp  flavors,  and  experience 
reported  in  [MATSUM0T084,  KER- 
NIGHAN84]  leads  us  to  make  the  following 


assumptions  about  the  activity  of  software 

reuse  and  about  reusable  software  parts. 

(1)  As  a  rule,  reusable  software,  especially 
reusable  code,  will  be  modified  each 
time  it  is  used  in  a  program.  The  sim¬ 
plest  modification  is  the  instantiation  of 
generic  parameters.  More  general 
modifications  include  enhancing  a 
software  part  by  adding  features,  re¬ 
stricting  it  by  hiding  features,  and 
implementing  it  using  features  provided 
by  others  [GOGUEN86],  If  software 
reuse  is  to  be  cost  effective, 
modifications  must  be  done  systemati¬ 
cally  using  "hooks"  provided  by  the 
software  part,  and  not  simply  by  chang¬ 
ing  code. 

(2)  Reusable  software  parts,  especially  reus¬ 
able  code,  must  be  built  for  reuse, 
either  from  scratch  or  by  extensive 
retrofitting  [MATSUM0T084],  While 
it  is  possible  to  take  code  and  "massage" 
it  in  order  to  reuse  it,  we  claim  that 
what  is  really  being  reused  is  a  design, 
and  that  the  massaging  constitutes  writ¬ 
ing  new  code  from  a  reused  design. 
When  a  potentially  reusable  part  is 
built,  its  author  must  consider  the  fact 
that  it  will  be  reused.  This  means, 
among  other  things,  that  the  part 
should  provide  an  appropriate  abstrac¬ 
tion,  that  is,  behavior  that  is  general 
enough  to  be  useful  in  more  than  one 
program  but  specific  enough  so  that 
there  is  not  a  large  performance  penalty 
for  generality.  The  part  should  also 
provide  appropriate  hooks  for  sys¬ 
tematic  external  modification.  Other 
characteristics  of  reusable  software  are 
described  in  (STDENNIS86]  which  was 
produced  by  the  RaPIER  project. 

(3)  Reuse  will  be  most  cost  effective  when 
reusers  are  familiar  with  the  nature  of 
the  software  parts  that  are  available  to 
them.  This  does  not  mean  knowing  a 
software  part’s  behavior.  No  reuser  can 
be  familiar  with  the  behavior  of  all  the 
parts  in  a  repository,  although  the  locat¬ 
ing  process  will  be  quicker  if  the  reuser 
is  familiar  with  the  behavior  of  some 
candidate  parts.  What  "familiar  with  the 
nature  of  the  software  parts"  means  is 
that  the  reuser  understands  "how  things 
work."  For  example,  Unix(TM)  users 
understand  that  Unix  utilities  expect  a 


standard  kind  of  input  and  output,  and 
that  piping  can  connect  these  utilities  in 
a  systematic  way  [KERNIGHAN84], 
Unix  users  build  programs  out  of  reus¬ 
able  parts  fairly  easily  because  they 
understand  "how  things  work." 

3.  THE  REUSE  PROCESS 

There  are  four  steps  in  reusing  a 
software  part,  and  one  crucial  requirement  on 
reused  parts. 

Before  a  part  is  reused,  it  must  be: 

o  Located.  A  candidate  for  reuse  must  be 
found  among  all  the  reusable  parts  that  are 
archived  in  some  software  database  manage¬ 
ment  system  (SBMS).  The  SBMS  must 
present  users  with  a  lucid  classification 
scheme  that  appeals  to  their  intuition.  Each 
candidate  part  must  be  specified  in  such  a 
way  that  the  reuser  is  likely  to  find  it. 

o  Understood.  Understanding  a  part  means 
knowing  what  it  does,  how  it  does  it,  and 
how  it  can  be  reused.  All  these  facts  must  be 
included  in  each  part’s  specification.  "What" 
is  the  part’s  function;  "how"  its  operational 
behavior  (for  example,  its  reliability  or  per¬ 
formance);  "how  it  can  be  reused"  includes 
its  expectations  from  its  environment  and  the 
interface  through  which  it  is  modified  and 
incorporated  into  the  program  under  develop¬ 
ment.  Specifications  can  be  natural  language 
comments,  formal  specifications  in  a  language 
such  as  the  predicate  calculus,  operational 
specifications  in  a  language  such  as  Prolog,  an 
Ada  interface  description,  and  so  forth.  Code 
as  the  only  specification  is  unacceptable. 
Needing  to  read  a  part’s  code  because  of  the 
poor  quality  of  its  specification  is  not  desir¬ 
able. 

When  the  part  is  being  reused,  it  must  be 

o  Tailored.  We  assume  that  modifications 
will  be  needed.  There  are  two  kinds  of 
modifications:  { I }  making  new  entities 
(types)  from  old  by  modifying  something 
about  the  entity:  for  example,  making  a 
binary  sort  routine  from  a  binary  search  rou¬ 
tine  by  adding  functionality  to  the  search;  or 
(2 1  making  new  instances  of  types:  for  exam¬ 
ple,  instantiating  an  Ada  generic  with  param¬ 
eters  that  particularize  it  for  the  program  in 
which  it  is  included. 


Changing  code  is  the  least  desirabi'  way  to 
make  a  new  entity  or  new  instance.  Code 
should  be  tailored  from  the  outside  using 
"hooks"  such  as  parameters.  [GOGUEN86] 
lists  eight  techniques  for  constructing  new 
entities  from  old;  none  necessitates  internal 
code  modification. 

o  Connected.  After  a  part  is  tailored,  it  is 
ready  to  be  put  together  with  the  rest  of  the 
reusable  parts  that  form  the  program  under 
development  Connection  requires  build¬ 
time  support  in  the  form  of  a  module  inter¬ 
connection  language  such  as  LIL 
(GOGUEN86]  or  PSDL  [ISSI86].  Program 
construction  is  best  accomplished  in  a 
development  environment  with  module  inter¬ 
connection  language- based  tools.  The 
RaPIER  project  is  developing  such  an 
environment  for  constructing  prototypes. 

There  are  many  requirements  for  reusable 
software  parts  [STDENNIS86];  one  is  crucial: 

o  Insulated  from  its  Environment.  A  reused 
part  must  cause  only  the  effects  which  consti¬ 
tute  its  documented  behavior.  It  must  not  be 
a  danger  to  the  rest  of  the  program  by  caus¬ 
ing  undocumented  effects.  It  must  be  built 
not  to  interfere  with  any  environment  in 
which  it  finds  itself.  Conversely,  a  reused 
part  must  not  allow  the  environment  to 
endanger  it.  It  must  not  make  implicit 
assumptions  about  its  environment  that, 
when  violated,  will  not  allow  it  to  function. 
It  must  not  be  open  to  uncontrolled 
modification  of  its  internal  state  by  its 
environment. 

4.  PROGRAMS  BUILT  FROM  REUS¬ 
ABLE  CODE  SHOULD  BE  SINGLE 
PARADIGM 

"A  [programming]  paradigm  is  a  style 
of  programming,  supported  by  system  facili¬ 
ties,  that  provides  leverage  in  a  range  of  pro¬ 
gramming  tasks"  [BOBROW85].  Some  com¬ 
mon  paradigms  and  languages  which  support 
them  are:  procedure  based  (Ada),  functional 
(Lisp),  logic  programming  (Prolog),  object- 
oriented  (Smalltalk),  and  rule-oriented 
(OPS5).  This  paper  argues  that  programs 
built  from  reusable  software  parts  will  have 
to  exhibit  a  single  paradigm.(I)  (2)  By  impli¬ 
cation,  the  reusable  parts  that  compose  such 


programs  will  have  to  fit  the  paradigm. 

We  have  concluded  that  programs 
built  from  reusable  parts  should  exhibit  a 
single  paradigm  at  the  top  (interconnection) 
level.  That  is,  the  modules  that  are  con¬ 
nected  and  the  connections  themselves 
should  all  be  of  a  single  style.  Internally 
modules  could  be  implemented  in  a  variety 
of  styles;  however,  the  interfaces  they 
present  to  the  reuser  should  be  semantically 
uniform. 

One  major  argument  for  a  single  para¬ 
digm  is  that  reusable  parts  that  were  not 
"made  for  each  other"  must  work  together; 
that  is,  cooperate  to  achieve  the  system’s  goal 
while  not  interfering  with  each  other.  This  is 
more  likely  to  occur  when  all  the  reused  parts 
are  of  a  single  paradigm:  subroutines,  Ada 
packages,  flavors,  and  so  forth.  Another 
major  argument  for  single  paradigm  parts  is 
that  all  programs  require  run-time  support 
and  that  simultaneous  run-time  support  for 
multiple  paradigms  is  not  usually  available. 
These  same  arguments  also  justify  programs 
composed  of  reusable  parts  written  in  the 
same,  multi-paradigm  programming  language. 
However,  Ada  is  not  a  multi-paradigm 
language,  and  most  new,  sharable  software 
will  be  developed  in  Ada.  Therefore  it  is 
more  practical  to  recommend  a  single  para¬ 
digm  for  all  the  reusable  parts  in  any  program 
than  to  recommend  several  paradigms  imple¬ 
mented  in  the  same  multi-paradigm  language. 

We  now  discuss  how  single- paradigm 
programming  aids,  to  a  greater  or  lesser 
degree,  in  each  step  of  the  reuse  process 
presented  in  the  previous  section. 

(1)  Locating.  The  major  contributors  to 
findable  parts  are  good  specifications 
and  an  SBMS  with  a  perspicuous 
classification  scheme.  A  single  para¬ 
digm  can  help  somewhat,  in  that  classi¬ 
fying  the  same  sort  of  entity  is  easier 
than  trying  to  put  functions,  objects, 
logic  routines,  rules,  etc.  into  the  same 
classification  scheme.  In  addition, 
library  management  tools  can  interact 
with  standard  components  in  a  standard 
manner,  allowing  more  possibilities  for 
automation.  For  example,  a  tool  could 
more  easily  produce  explanations  of 
parts’  behavior  by  parsing  the  parts  if 


the  parts  all  follow  the  same  semantic 

pattern. 

(2)  Understanding.  When  users  need  to 
understand  only  one  sort  of  thing,  they 
accumulate  background  about  that  sort 
of  thing.  Thus  they  know  basically  how 
any  part  acts  before  investigating  it  and 
need  only  the  added  knowledge  of  pre¬ 
cisely  what  it  does.  For  example, 
understanding  filters  in  general  means 
that  a  user,  encountering  a  filter,  needs 
to  ask  only  what  the  filter  filters  to  have 
complete  knowledge  of  how  the  filter 
behaves.  When  users  need  to  under¬ 
stand  many  paradigms,  they  usually  do 
not  accumulate  extensive  knowledge 
about  each. 

(3)  Modifying.  [GOGUEN86]  lists  eight 
kinds  of  modifications  that  will  produce 
new  entities  from  old.  When  programs 
are  built  from  one  type  of  entity,  it  is 
economical  to  invest  in  learning  how  to 
supply  the  hooks  for  external 
modifications  of  reusable  parts  in  this 
paradigm.  The  hooks  then  make  it  easy 
for  reusers  to  modify  parts  correctly. 
Even  if,  in  extreme  situations,  code 
must  be  modified  internally,  the  form 
of  the  code  and  its  general  behavior  will 
be  familiar,  making  it  less  likely  that  an 
internal  modification  will  introduce 
errors  into  the  code.  When  users 
write  reusable  code  in  many  paradigms, 
they  will  not  have  learned  patterns  for 
"hooks,"  and  so  will  make  more  provi¬ 
sions  of  external  modification. 
Reusers,  in  turn,  will  have  to  use  less 
well  thought  out  modification  facilities 
that  are  also  less  familiar  to  them. 

(4)  Connecting.  Two  major  benefits  of  sin¬ 
gle  paradigm  programming  apply  in  this 
step.  As  mentioned  above,  program¬ 
ming  with  single-paradigm  parts  guaran¬ 
tees  that  the  parts  will  fit  together  and 
that  their  run-time  support  can  be  pro¬ 
vided.  In  addition,  users  will  learn  pat¬ 
terns  for  combining  parts,  thereby 
becoming  more  productive.  The  con¬ 
nection  step  should  be  supported  by  a 
program  construction  environment 
[GOGUEN86]  that  is  based  on  a 
module  interconnection  language 
(MIL).  If  the  module  interconnection 
language  is  tuned  to  the  paradigm,  it 


can  provide  concise  primitives  for  para¬ 
digm  specific  things  such  as  message 
passing  for  objects.  Thus  users  have  to 
write  less  and,  more  importantly,  to 
think  less  since  the  MIL’s  primitives 
obviate  the  need  to  built  paradigm 
specific  capabilities  "by  hand." 

(5)  Insulation.  There  are  paradigms  such 
as  the  object-oriented  paradigm  dis¬ 
cussed  below  that,  through  information 
hiding,  provide  insulation  between  parts 
and  their  environment  in  both  direc¬ 
tion.  In  addition,  when  all  parts  in  a 
program  follow  any  single  paradigm, 
they  are  far  less  likely  to  interfere  with 
each  other.  Multiple  paradigms  means 
different  parts  have  different  expecta¬ 
tions  of  and  behavior  toward  the 
environment,  which  can  lead  to 
interference. 


5.  THE  OBJECT-ORIENTED  PARA¬ 
DIGM 

The  RaPIER  project  has  chosen  the 
object-oriented  paradigm  for  its  reusable 
software  parts.  Object-oriented  program¬ 
ming  is  the  paradigm  embodied  in  Smalltalk 
[GOLDBERG83]  and  the  Lisp  Flavor  system 
[CANNON821.  The  concept  of  an  object  as  a 
named  computational  entity  with  identifiable 
behavior  is  central  to  object-oriented  pro¬ 
gramming.  An  object's  behavior  is  its  reac¬ 
tions  to  the  set  of  messages  it  "understands," 
where  a  message  is  a  request  to  initiate  pro¬ 
cessing  or  provide  information,  and  "under¬ 
standing"  means  call  ...  denotes  an  action, 
and  sending  a  message  ...  makes  a  request  ... 

.  [T]  he  interpretation  of  the  message  is  left 
entirely  up  to  its  recipient."  [RENTSCH82]. 

Object-oriented  programming  can 
proceed  top-down  [BOOCH83]  or  bottom-up. 
Bottom-up  object-oriented  programming 
begins  with  a  collection  of  reusable  software 
objects  such  as  the  Smalltalk  system’s  objects 
or  a  user’s  personal  library.  Objects  for  the 
problem  at  hand  are  built  up  by  combining 
more  primitive  (system  or  user-defined) 
objects.  Eventually  the  system  contains  the 
appropriate  objects  to  solve  the  problem  at 
hand.  Then  a  program  that  uses  these 
objects  is  written,  often  in  a  module  intercon¬ 
nection  language  such  as  CMESA,  PSDL  or 
LIL.  Bottom-up  object-oriented 


programming  is  a  natural  way  to  exploit  a 
software  repository’s  resources.  The  program 
under  construction  can  certainly  be  designed 
top-down,  but  that  design  will  take  into 
account  the  available  resources. 


(1)  This  does  not  mean  that  every  program 
must  conform  to  the  same  paradigm, 
only  that  each  individual  program  will 
be  single-paradigm. 

(2)  Some  problems  should  be  solved  by 
programs  written  in  languages  such  as 
Loops  [STEFIK86],  that  integrate  mul¬ 
tiple  paradigms.  A  program  in  a  multi- 
paradigm  language  offers  some  of  the 
same  benefits  we  claim  for  single¬ 
paradigm  programs. 


Object-oriented  programming  has 
specific  benefits  in  the  RaPIER  setting.  One 
important  one  has  to  do  with  the  fact  that  a 
prototype  is  a  vehicle  for  communicating 
about  requirements  between  customers  and 
product  implementers.  Traditional  black-box 
requirements  are  difficult  to  discuss  even 
among  computer  specialists,  but  especially 
between  domain  experts  who  are  not  com¬ 
puter  scientists  and  the  computer  scientists 
who  are  solving  their  problems.  (ZAVE85] 
states  that  "An.. .important  factor  in 
user/analyst  communication  is  the  ability  of 
the  user  to  grasp  and  evaluate  the  concepts 
behind  any  proposal.  Experienced  systems 
analysts  report  that  an  explicit  operational 
model  is  much  more  helpful  than  black-box 

requirements . *  That  operational  model  has 

structure;  it  is  the  structure  that  facilitates 
discussion  between  customers  and  develop¬ 
ers.  We  conjecture  that  users  interacting 
with  a  prototype  will  view  it  as  a  collection  of 
autonomous,  concurrent  processes. 
Although  they  will  not  think  in  computer  sci¬ 
ence  terms,  of  objects  with  local  state  and 
methods,  and  of  asynchronous  communica¬ 
tion  by  message  passing,  they  will  think  of  a 
collection  of  processes,  modules,  or  objects, 
each  responsible  for  some  part  of  the 
prototype’s  behavior.  And  although  the 
objects  from  which  the  prototype  is  built  will 
not  be  the  same  as  the  objects  the  user  ini¬ 
tially  imagines,  the  builder  can  elucidate  the 


prototype’s  structure  to  the  user,  providing 
the  structured  communication  vehicle  recom¬ 
mended  in  [ZAVE85].  Another  benefit  of 
objects  in  the  prototyping  milieu  is  that  they 
localize  change,  yielding  an  easily  modifiable 
prototype.  This  idea  is  examined  in  detail 
below. 

Objects  aid  the  reuse  process  in  the  following 
ways: 

(1)  Locating.  [BOOCH83a]  motivates  an 
object  oriented  design  approach  by 
pointing  out  that 

"No  matter  what  the  particular  applica¬ 
tion,  the  problem  space  is  rooted  some¬ 
where  in  the  real  world  ...in  the  prob¬ 
lem  space  we  have  some  real-world 
objects,  each  of  which  has  a  set  of 
appropriate  operations.... 

"Whenever  we  develop  a  software  sys¬ 
tem,  we  ...  model  a  real-world 
problem  ...  .  No  matter  what  the 

implementation,  our  solution  space 
parallels  the  problem  space.  ...the  pro¬ 
grammer  abstracts  the  objects  in  the 
problem  space  and  implements  the 
abstraction  in  software." 

We  believe  that  both  locating  and 
understanding  reusable  parts  -  is  facili¬ 
tated  when  the  parts  are  the 
programmer’s  "natural"  abstraction. 

(2)  Understanding.  As  stated  above, 
objects  are  a  natural  model  of  the  sort 
of  software  component  that  many  pro¬ 
grams  should  comprise.  Thus  people 
reusing  them  will  have  some  intuitive 
understanding  of  "how  they  work"  even 
before  studying  the  paradigm.  Objects 
(rather  than  subroutines,  data  struc¬ 
tures,  or  general  code  fragments)  are 
also  an  appropriate  unit  to  understand 
in  detail.  They  present  complete 
enough  behavior  to  be  understood  and 
used  as  units  rather  than  as  incomplete 
fragments,  and  to  be  combined  without 
internal  modification.  The  work  on 
abstract  data  types  [LISKOV751, 
Smalltalk  [GOLDBERG831,  and  Fla¬ 
vors  [CANNON82!  bears  this  out. 

The  object’s  interface  is  the  set  of  mes¬ 
sages  it  can  handle;  each  method  can  be 
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specified  separately.  This  is  a  clean, 
simple  interface:  it  is  specified  in  small 
enough  chunks  to  be  easily  grasped;  it 
describes  operations  (methods),  a 
notion  that  the  user  is  already  intui¬ 
tively  comfortable  with.  Thus  the  total 
specification  presents  a  complete 
abstraction  in  easily  understandable 
chunks. 

(3)  Modifying.  An  object  is  a  complete 
unit  of  behavior;  if  it  was  built  for 
reuse  it  presents  an  'appropriately  use¬ 
ful  abstraction”  (see  Assumption  B), 
and  thus  the  methods  it  provides  will 
not  have  to  be  changed.  Therefore, 
modifying  an  object  will  mean  enhanc¬ 
ing  or  restricting  its  behavior;  both  can 
be  done  from  the  outside  by  adding  or 
deleting  methods  respectively.  It  is 
good  software  engineering  to  consider 
all  changes  to  be  either  enhancements 
or  restrictions,  and  to  simply  disallow 
internal  changes  to  code.  This  is  possi¬ 
ble  under  Assumption  B. 

The  object  is  a  well-understood  concept; 
reusers  who  modify  it  will  know  its  pat¬ 
tern,  and  be  able  to  modify  it  in  the 
pattern.  A  module  interconnection 
language  can  provide  primitives  for  re¬ 
stricting  an  object’s  interface.  For 
enhancing  the  interface,  reusable 
objects  can  include  some  hidden 
methods  (that  is,  methods  not  available 
to  client  software)  that  can  serve  as 
primitives  for  creating  new  methods. 
Hidden  methods  ensure  that 
modifications  are  correct  in  that  they 
present  a  modifier  with  the  same  sort  of 
"safe"  interface  that  they  provide  for 
client  software.  Hidden  methods  are 
one  of  the  investments  that  can  be 
made  when  writing  software  for  reuse. 

(4)  Connecting.  An  object-oriented  pro¬ 
gram  is,  in  concept,  a  loosely  coupled 
collection  of  autonomous,  concurrently 
active  objects  which  communicate  by 
message  passing.  Each  object  controls 
its  own  processing  by  interpreting  the 
messages  it  receives  and  deciding  how 
to  handle  each  one  based  on  its  state 
and  methods.  This  model  has 
undemanding  connection  requirements: 
the  module  interconnection  step  must 


only  establish  "wires"  for  messages  to 
flow  across,  and  provide  some  means  of 
kicking-off  the  system.  If  all  objects 
name  the  targets  of  the  messages  they 
send,  interconnection  can  be  totally 
automated.  The  model  does  require 
run-time  support  for  message  passing. 

(5)  Insulation  from  the  Environment. 
Objects  provide  information  hiding,  not 
just  modularity.  No  object  can  manipu¬ 
late  another's  state  except  through  well 
defined  interfaces,  the  methods;  objects 
control  their  processing  by  interpreting 
messages.  Thus  the  likelihood  of  the 
environment  spoiling  an  object's  state  is 
vanishingly  small.  By  filtering  their 
requests,  objects  do  not  allow  interfer¬ 
ence.  Because  each  object  protects 
itself,  interference  is  prevented  in  both 
directions. 

6.  FUTURE  WORK 

In  order  to  make  the  object-oriented 
paradigm  work  in  our  RaPIER  prototyping 
environment,  we  are  investigating  these 
questions: 

o  What  is  an  adequate  implementation  of  an 
object/ message  passing  model  in  an  Ada 
based  prototyping  environment. 

o  What  features  of  the  object  model  can  be 
implemented  in  Ada?  We  will  learn  to  make 
Ada  parts  that  have  as  many  of  the  charac¬ 
teristics  of  Smalltalk-like  objects  as  Ada  can 
support  and  learn  how  to  do  without  the 
characteristics  Ada  cannot  support.  In  partic¬ 
ular,  we  shall  investigate  how  to  implement 
inheritance  sufficiently  well  to  obtain  the 
time  and  effort  savings  from  making  a  new 
object  out  of  operations  and  data  structures 
inherited  from  parent  objects. 

o  What  are  the  build-time  capabilities 
needed  to  support  program  construction  by 
Ada  object  connection? 

o  What  are  the  run-time  capabilities  needed 
to  support  a  system  of  Ada  objects? 

o  What  kinds  of  modifications 
[GOGUEN86]  are  necessary  to  reuse  objects 


and  how  do  Ada  objects  have  to  be  con¬ 
structed  to  allow  these  modifications  to  be 
made  externally? 
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ABSTRACT 


This  paper  identifies  fundamental  issues  relevant  to  the  successful  reuse  of  Ada  software  in  Mis¬ 
sion  Critical  Computer  Resource  (MCCR)  applications.  The  reusability  of  an  Ada  program  is  defined 
in  the  context  of  three  criteria  for  evaluating  the  degree  to  which  Ada  software  is  reusable.  These  cri¬ 
teria  are  important  to  writing  reusable  software  for  the  timely  transition  of  MCCR  systems  to  the  Ada 
Language. 
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Prologue 

A  central  idea  in  the  design  of  the  Ada 
language  (Department  of  Defense  1983)  is  to 
assemble  a  program  from  independently  pro¬ 
duced  software  components.  Therefore,  the 
reusability  of  Ada  software  components 
(STARS  1985)  is  viewed  as  the  cornerstone 
in  reducing  the  cost  of  developing  Mission 
Critical  Computer  Resource  (MCCR)  sys¬ 
tems.  If  the  promise  of  reusing  Ada  software 
components  is  fulfilled,  the  reduction  in  cost 
is  expected  to  be  significant  (Anderson 
1985) 

There  is  little  practical  experience  in 
reusing  Ada  software  components  for  MCCR 
applications.  In  the  initial  transitions  to  the 
Ada  language  the  reuse  of  software  com¬ 
ponents  may  be  adversely  affected  by  funda¬ 
mental  issues  that  affect  the  writing  of  reus¬ 
able  components.  Understanding  these 
issues  is  necessary  to  managing  the  transition 
if  the  potential  costs  and  benefits  of  Ada 
software  reusability  are  to  be  predicted. 


Approach 

Several  studies  have  reported  on  transi¬ 
tioning  currently  deployed  MCCR  systems  to 
the  Ada  language  (Friedman  1985).  These 
studies  have  focused  on  evaluating  the  ade¬ 
quacy  of  the  Ada  language  to  meet  existing 
performance  efficiency  requirements  and  do 
not  specifically  consider  the  reuse  of  transi¬ 
tioned  software  among  different  MCCR  appli¬ 
cations. 

The  results  from  the  studies  indicate 
that  in  transitioning  to  the  Ada  language, 
rigid  performance  requirements  upon  the 
run-time  environment  will  necessitate  the  use 
of  Ada  constructs  where  their  level  of 
abstraction  may  be  comprised  by  explicit  and 
implicit  dependencies  upon  the  run-time 
environment.  Consequently,  developing  Ada 
software  that  is  both  reusable  and  meets  the 
performance  requirements  of  MCCR  applica¬ 
tions  presents  a  conflict.  The  conflict  is  ex¬ 
acerbated  by  programming  practices  that  have 
exploited  idiosyncrasies  of  the  execution 


environment.  These  practices  have  resulted 
in  application  specific  techniques  that  are 
efficient  but  reduce  the  level  of  abstraction 
essential  for  software  reuse. 

For  example,  one  requirement  that  per¬ 
vades  MCCR  applications  is  the  facility  for 
periodic  control  of  both  concurrent  and  serial 
processing.  Traditionally  this  requirement 
has  been  satisfied  by  variations  of  the  Cyclic 
Executive  which  has  become  the  classical 
paradigm  for  examining  the  efficacy  of  using 
the  Ada  language  for  real-time  programming 
(Hood  1985;  MacLaren  1980;  Phillips  & 
Stevenson  1984).  Often  the  adaptation  of 
the  Cyclic  Executive  to  provide  efficient  use 
of  processing  resources  can  lead  to  dependen¬ 
cies  by  the  application  software  on  program¬ 
ming  techniques  that  are  nonreusable.  These 
techniques  may  persist  after  the  transition 
depending  upon  the  implementation  of  the 
Ada  Run-Time  System  (RTS).  In  under¬ 
standing  the  issues  of  software  reuse,  the 
ramifications  of  such  techniques  must  be 
understood  to  perform  tradeoff  analysis 
between  efficiency  and  reuse  when  transition¬ 
ing  to  the  Ada  language. 

To  understand  the  reuse  of  Ada 
software  components  an  approach  must 
address,  at  a  minimum,  the  issues  of  writing 
efficient  code  that  is  reusable  in  different 
run-time  environments.  Particular  emphasis 
should  be  given  to:  performance  efficiency 
requirements  of  MCCR  applications  as  they 
affect  software  reuse,  program  composition 
features  of  the  Ada  language  that  facilitate 
the  creation  and  use  of  reusable  components, 
and  the  implementation  options  of  the  Ada 
RTS  that  may  compromise  software  reuse. 
In  this  paper,  the  technical  foci  is  directed 
towards  the  latter  two  topics. 

ADA  Software  Reusability 

Software  reusability  comprises  the  con¬ 
cept  to  execute  a  program  in  an  execution 
environment  different  from  that  in  which  it 
was  originally  developed,  i.e.,  transportability, 
and  the  concept  to  combine  components 
from  different  programs  in  the  development 
of  a  new  program,  i.e.,  reusability.  The 
comprehensive  support  of  the  Ada  language 
for  modem  software  engineering  principles, 
viz.,  abstraction,  composition,  encapsulation, 
and  instantiation,  provide  a  framework  for 
writing  reusable  software.  The  distinction 


made  in  this  paper  between  the  concepts  of 
reusability  and  transportability  of  Ada 
software  is  discussed  in  the  following  para¬ 
graphs.  This  distinction  partially  resolves  the 
inherent  ambiguity  of  these  two  concepts  and 
is  consistent  with  the  notion  of  both  re¬ 
usability  "in  the  large"  and  "in  the  small" 
(Lubars  1986). 

Program  Transportability 

The  transportability  of  an  Ada  program 
is  defined  as  the  ability  of  a  program  to  com¬ 
plete  functionally  equivalent  execution  in 
different  environments  consistent  with  the 
Ada  language.  Transportability  is  measured 
by  the  degree  this  execution  can  be  achieved 
without  modifying  the  source  code.  This 
definition  is  derived  from  an  earlier  one 
(Obemdorf  et  al  1982)  and  work  that  has 
been  previously  reported  (Nissen  &  Wallis 
1984;  Pappas  1985).  The  stipulation  for 
equivalent  execution  rather  than  identical 
execution  recognizes  that  the  processing 
capacity  of  the  execution  environment  and 
the  sophistication  of  the  compiling  system 
may  affect  the  execution  behavior  of  the  pro¬ 
gram  within  the  semantics  of  the  Ada  Refer¬ 
ence  Manual  (RM)  (Volz  et  al  1986).  For 
example,  the  number  of  times  a  loop  body  is 
performed  may  vary  because  the  source  code 
invites  compiler  optimization.  In  addition,  it 
does  not  exclude  the  use  of  representation 
specifications  to  influence  execution  since 
their  use  is  perceived  as  essential  to  most 
MCCR  applications. 

Program  Reusability 

The  reusability  of  an  Ada  program  is 
defined  as  the  ability  of  one  or  more  of  its 
components  to  execute  with  identical  func¬ 
tionality  in  the  construction  of  a  new  pro¬ 
gram.  Reusability  is  measured  in  the  degree 
that  different  components  of  the  program  can 
be  used  to  construct  new  programs  in  the 
same  and  different  execution  environments. 
This  definition  is  more  stringent  than  the  one 
recently  proposed  for  developing  reusability 
guidelines  (Braun  et  al  1985)  since  three 
important  criteria  for  evaluating  program  re¬ 
usability  are  mandated:  the  transportability  of 
the  program,  the  orthogonality,  i.e.,  func¬ 
tional  independence,  of  its  composition,  and 
its  freedom  from  dependencies  on  a  specific 
implementation  of  the  Ada  Run-Time  Sys¬ 
tem  (RTS).  The  definition  does  not 


discriminate  between  writing  reusable  com¬ 
ponents  and  programs  where  their  constituent 
components  can  be  reused. 

A  necessary  first  step  to  reusing  com¬ 
ponents  in  different  execution  environments 
is  to  achieve  the  transportability  of  the  pro¬ 
gram.  When  only  the  program  is  to  be 
reused,  the  distinction  between  reusability 
and  transportability  is  the  fidelity  of  execu¬ 
tion,  i.e.,  equivalent  or  identical.  When  a 
component  is  to  be  reused  in  different  pro¬ 
grams,  e.g.,  an  Ada  generic  unit,  the  tran¬ 
sportability  criteria  ensures  a  context  for  vali¬ 
dating  execution. 

Composition  Orthogonality 

In  discussing  composition  orthogonality, 
it  is  convenient  to  introduce  degrees  of  re¬ 
usability.  A  component  whose  potential  for 
reuse  is  low  is  said  to  be  weakly  reusable, 
while  a  component  whose  potential  for  reuse 
is  high  is  said  to  be  strongly  reusable.  These 
represent  the  extremes  of  reusability.  Source 
modifications  and  limited  applicability  are 
expected  with  weak  reusability,  while  with 
strong  reusability  no  source  modifications  and 
potentially  frequent  applicability  are  expected. 
An  effectively  reusable  component  differs 
from  a  strongly  reusable  component  only  in 
that  some  source  modifications  may  be 
required  due  to  Ada  language  rules.  In  prac¬ 
tice  weak  reusability  is  to  be  avoided,  strong 
reusability  strived  for,  with  effective  reusabil¬ 
ity  actually  opined. 

The  orthogonality  of  a  program’s  com¬ 
position  is  an  attribute  of  the  program  which 
reflects  the  independence  of  its  components 
from  the  enclosing  context  The  stronger  a 
component’s  dependence  on  its  context,  the 
less  likely  its  potential  foi  .cuse  since  more 
of  the  context  must  be  transported  with  it, 
i.e.,  weak  reusability  is  more  likely.  Con¬ 
versely,  the  weaker  a  component’s  depen¬ 
dence  on  its  context,  the  greater  the  potential 
for  the  component’s  reuse  since  little,  if  any, 
of  the  surrounding  context  need  be  tran¬ 
sported  with  it,  i.e.,  strong  reusability  is  more 
likely.  When  coupled  with  programming  for 
generality,  striving  for  context  independence 
will  yield  effectively  reusable,  if  not  strongly 
reusable,  software  components. 


Composition  orthogonality  is  not  an 
issue  in  program  transportability  since  the 
entire  context  of  each  program  component  is 
transported  to  the  new  execution  environ¬ 
ment.  It  is  only  when  a  component  is 
extracted  from  its  context  that  composition 
orthogonality  becomes  an  issue.  The  excep¬ 
tion  to  this  is  a  program  whose  main  subpro¬ 
gram  has  parameters.  But  in  this  situation, 
the  context  dependency  is  on  the  execution 
context  and  not  the  application  context. 
Therefore,  the  issue  is  one  of  transportability 
rather  than  reusability. 

Degrees  of  reusability  are  illustrated  in 
Example  1,  where  two  versions  of  a  binary 
search  are  shown.  Example  l.a,  which  is  typ¬ 
ical  of  binary  searches  used  in  practice,  is 
weakly  reusable  for  several  reasons.  First,  it 
has  several  context  dependencies.  Reuse  of 
this  example  requires  providing  three  entities 
in  the  new  context:  a  named  number, 
Max_Table_Elements,  a  type  named  Ele¬ 
ment  Type,  and  an  array  named  Table  with 
the  structure  shown.  If  these  entity  names  or 
the  array  structure  are  not  appropriate  in  the 
new  context,  then  the  component  must  be 
modified.  A  second  problem  with  this  exam¬ 
ple  is  its  lack  of  generality.  In  addition  to 
only  providing  a  binary  search  for  a  particular 
array,  it  strongly  depends  on  the  array  index 
subtype  being  a  subtype  of  Positive.  This 
dependency  is  explicit  in  the  Mid_Point  cal¬ 
culation  and  in  the  calculations  of  the  left 
and  right  end  points.  The  dependency  is 
implicit  in  the  use  of  zero  to  indicate  that  the 
element  is  not  found  in  the  Table.  The 
result  subtype  of  the  Binary_Search  function. 
Natural,  extends  the  array  index  subtype  by 
one  value  to  allow  it  to  serve  a  dual  purpose 
—  return  the  array  index  upon  a  successful 
search  and  indicate  failure  upon  an  unsuc¬ 
cessful  search. 

Example  l.b  illustrates  a  strongly  reus¬ 
able  version  of  the  binary  search.  Here,  the 
function  has  been  encapsulated  within  a  gen¬ 
eric  package.  Through  the  use  of  generic  for¬ 
mal  parameters,  all  context  dependencies 
have  been  removed.  In  addition,  the  param¬ 
eterization  in  Example  l.b  encompasses  all 
possible  generalizations  of  this  binary  search 
that  do  not  change  its  functionality. 
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Exaaple  l.A  -  Weak  Reusability 

Table  :  array  (1  ..  Nax_TableJEleaents)  of  Eleaent_Type; 

•  •  • 

function  Binary_Search  (Elaaant  s  in  EIeaent_Type)  return  Natural  is 

Left_Point  s  Positive  s«  l; 

Ri|ht_Point  :  Positive  s«  Hax_Table_Eleaents« 

Hid_Point  :  Positive; 

begin 

while  Left_Point  <«  Ri|ht_Point  loop 

Hid_Point  :«  <Left_Point  ♦  Ri|ht_Point)  /  2; 
if  Eleaent  <  Table  <Hid_Point)  then 
Ri*ht_Point  :*  Hid_Point  -  1; 
at  sit  Table  (HidJPoint)  <  Eleaent  then 
Lef t_Point  s*  Mid_Point  ♦  1; 
else 

return  Nid_Point; 
end  if; 
end  loop; 
return  0; 

end  Binary.Search; 


generi c 


type  Element  JType  is  pri vats', 
typs  IndexJType  is  (<>); 

typs  Tab  1  e  JType  is  array  (IndexJType  rangs  <>)  of  Element  JType; 

with  function  "<"  (Left,  Right  :  Element  JType)  return  Boolean  is  <>; 

package  Binary_Search_Package_TempIate  is 

function  Binary  J5earch  (Table:  TableJType;  Element:  Eleaent_Type) 

return  IndexJType; 


Not_Found  :  exception’, 

end  Binary_Search_Package  JTemplate; 

package  body  Binary_Search_PackageJTemplate  is 

function  Binary_Seareh  (Table:  TableJType;  Element:  Element JType) 

return  IndexJType  is 

Left_End  :  Index_Typ*  :=  Table'First; 

Right_End  :  Index_Type  :*  Table' Last; 

Nid_Point  :  Index_Type; 

begin 

if  Table' Last  <  Table' First  then 
raise  NotJFound; 

else 

while  Left_End  <  Right_End  loop 

Hid_Point  :*  Index  JType' Val  ( Index_Type* Pos  (Left_End) 

♦  IndexJType' Pos  (Right_End)  /  2>; 
if  Element  <  Table  (Hid_Point)  then 

Right_End  :*  Index  JType’ Pred  (Mid_Point); 
elsif  Table  (Hid_Point)  <  Element  then 

Left_End  :■  Index_Type’ Succ  (Hid_Point); 
else 

return  Mid_Point; 
end  if; 
end  loop ; 

if  Left_End  *  Right_End  and  then  Element  *  Table  (Left.End)  then 
return  Left_End; 

else 

raise  Not_Found; 
end  if; 
end  if; 

end  Binary_Search; 
end  Binary_Search_PackageJTemplate; 


While  there  is  no  difference  between 
effective  reusability  and  strong  reusability  in 
Example  l.b,  there  are  situations  where  a 
difference  may  occur.  For  example,  consider 
a  generic  subprogram  implementing  a  numer¬ 
ical  algorithm  such  that  the  algorithm 
requires  a  real  type.  The  "real"  type  is  a  gen¬ 
eric  formal  parameter  of  the  generic  subpro¬ 
gram.  If  only  standard  mathematical  opera¬ 
tions  are  required  for  this  type,  then  a  private 
type  can  be  used.  The  mathematical  opera¬ 
tions  would  be  generic  formal  function 
parameters,  with  appropriate  defaults,  to  the 
generic  subprogram.  If,  however,  accuracy 
demands  necessitate  the  use  of  floating  point 
or  fixed  point  attributes,  then  two  versions  of 
the  generic  subprogram  are  needed:  one  for 
floating  point  types  and  one  for  fixed  point 
types.  In  this  case  there  is  a  difference 
between  effective  reusability  and  strong  re¬ 
usability.  Both  versions  are  effectively  reus¬ 
able  but  neither  is  strongly  reusable. 

One  strongly  reusable  version  could  be 
written  that  would  necessitate  using  a  private 
"real"  type.  Several  additional  generic  formal 
subprograms  would  need  to  be  included  as 
generic  parameters,  but  rather  than  providing 
the  user  with  any  real  benefit,  these  subpro¬ 
grams  would  simply  serve  to  isolate  floating 
point  and  fixed  point  attribute  dependencies, 
perform  type  conversions,  etc.  While  this 
version  might  satisfy  the  strong  reusability 
notion  of  this  paper,  in  reality,  users  would 
not  be  likely  to  use  a  generic  component 
requiring  generic  actual  parameters  merely  to 
comply  with  Ada’s  language  rules. 

Components  that  are  effectively  or 
strongly  reusable  seem  to  be  consistent  with 
good  programming  style  so,  ideally,  ail  pro¬ 
gram  components  should  be  written  in  this 
manner.  This  would  maximize  the  reusabil¬ 
ity  of  the  program’s  components.  In  reality, 
this  is  not  likely  to  occur  since  MCCR  per¬ 
formance  issues  may  dictate  otherwise. 
While  the  binary  search  in  Example  l.b  may 
be  strongly  reusable,  program  tuning  may 
require  a  weakly  reusable  version.  In  particu¬ 
lar,  the  distributed  binary  search  due  to 
Knuth  (Bentley  1982)  may  be  needed  in  the 
tuned  program.  Since  the  distributed  search 
could  be  produced  by  a  program  generator  it 
may  still  be  correct  to  view  it  as  strongly 
reusable,  but  at  the  level  of  a  program  gen¬ 
erator. 


RTS  Dependencies 

The  potential  for  RTS  dependencies  to 
affect  the  reuse  of  Ada  program  units  can  be 
appreciated  by  reviewing  a  specific  example 
that  presents  a  dependency  on  a  particular 
implementation  of  task  scheduling.  This 
dependency  does  not  necessarily  prevent  pro¬ 
gram  execution  from  meeting  the  transporta¬ 
bility  criterion  when  the  dependency  is  not 
satisfied  in  the  environment  to  which  the 
program  is  transported  for  reuse.  However, 
successful  reuse  of  the  program  unit  that 
includes  the  dependency  cannot  be 
guaranteed  in  the  new  environment. 

The  example  is  contrived  to  expedite  a 
straightforward  discussion  and  the  referenced 
code  does  not  represent  recommended  use  of 
the  language  or  a  dependency  that  cannot  be 
mitigated  in  some  other  way.  The  example 
originated  from  a  revision  to  a  program  from 
the  Ada  Fair  benchmark  suite  (Bardin  et  al 
1985).  The  original  program  included  pack¬ 
ages  designed  to  control  access  to  a  shared 
variable  as  a  means  of  evaluating  the  integrity 
of  the  task  scheduler.  In  the  revised  version, 
the  access  control  task  has  been  modified  to 
service  concurrent  reader  and  writer  tasks 
where  the  access  protocol  is  biased  in  favor 
of  writer  tasks  to  simulate  real-time  updating 
of  the  shared  variable.  The  shared  variable  is 
of  a  composite  type  and  may  be  read  con¬ 
currently  by  more  than  one  task  providing  no 
task  has  been  granted  write  access.  Further¬ 
more,  writing  must  be  serialized  and  out¬ 
standing  writes  should  be  serviced  before  a 
task  is  granted  read  access,  since  writer  tasks 
are  assigned  highest  priority. 

The  two  code  fragments  to  be  examined 
are  shown  in  Example  2.  The  first  fragment 
is  the  select  statement  enclosed  by  the  task 
that  grants  read/write  access.  The  second 
fragment  is  the  timed  entry  statement 
enclosed  by  the  procedure  that  is  called  by 
the  writer  tasks.  The  dependency  is  associ¬ 
ated  with  the  use  of  the  COUNT  attribute  in 
the  iteration  scheme  of  the  while-loop  that  is 
designed  to  service  all  outstanding  write 
requests  before  a  new  read  is  accepted. 

The  RM  cautions  against  the  use  of  the 
COUNT  attribute  because  its  value  is  not 
stable.  In  this  instance  sufficient  stability  is 
only  required  to  ensure  that  the  Start_Write 


Enaaple  2  -  Implicit  RTS  Dependence 


w 
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entry  queue  is  not  decremented  prior  to 
accepting  the  Start_Write  entry.  This 
depends  upon  a  class  of  First-In-First-Out 
(FIFO)  task  scheduling  that  prevents  interr¬ 
uption  of  control  task  execution  until  it  is 
blocked  by  the  Stop_Write  entry  even  in  the 
presence  of  an  expired  timed  entry  state¬ 
ment.  The  dependency  requires  that  expira¬ 
tion  of  the  delay  does  not  result  in  run-time 
action,  viz.,  changing  the  state  of  the  delayed 
writer  task,  until  the  executing  task  is 
blocked  and  a  new  task  has  to  be  executed. 

This  dependency  does  not  preclude  suc¬ 
cessful  execution  in  a  different  environment 
where  task  scheduling  is  not  guaranteed  to 
maintain  the  stability  of  the  value  of  the 
COUNT  attribute.  For  instance,  an  RTS  that 
implements  a  preemptive  class  of  task 
scheduling  may  result  in  the  value  being 
decremented  after  the  evaluation  of  the 
while-loop  but  prior  to  accepting  the 
StartWrite  entry.  However,  because  of  the 
priority  of  the  writer  tasks  and  the 
Start  Write  entry  statement  following  the 
expired  delay,  the  number  of  queued 
requests  cannot  decrease.  Consequently,  pro¬ 
gram  transportability  is  achieved  since  execu¬ 
tion  is  functionally  equivalent  in  both 
environments. 

When  the  above  implicit  dependency  is 
not  clearly  stipulated,  the  control  task  may  be 
mistakenly  considered  to  be  strongly  reusable 
in  the  new  environment  on  the  basis  of  pro¬ 
gram  transportability.  An  attempt  to  reuse 
the  control  task  with  -  different  procedure  for 
writer  tasks  can  have  aberrant  execution 
behavior  in  an  environment  that  does  not 
guarantee  the  stability  of  the  COUNT  attri¬ 
bute.  A  simple  change  to  the  timed  entry 
statement  that  removes  the  Start_Write  fol¬ 
lowing  the  delay  can  cause  the  entry  queue 
count  to  reach  zero.  The  control  task  is  now 
forced  to  unexpectedly  wait  at  the 
Start_Write  resulting  in  disruption  to  perfor¬ 
mance  since  the  reader  tasks  are  dependent 
for  execution  on  a  write  request.  This  is  con¬ 
trary  to  the  guard  specification  of  the  enclos¬ 
ing  select  statement.  In  a  worst  case  situa¬ 
tion,  when  no  further  writes  are  requested, 
the  control  task  is  blocked  indefinitely  from 
execution. 

Epilogue 

This  paper  has  presented  a  refinement 
to  the  concept  of  reusability.  This 


refinement  provides  insight  into  understand¬ 
ing  issues  in  writing  reusable  Ada  software 
components  for  MCCR  applications.  Compo¬ 
sition  orthogonality  and  independence  from 
the  Ada  RTS  implementation  are  identified  as 
useful  criteria  for  assessing  program  reusabil¬ 
ity.  Understanding  these  criteria  will  allow 
varying  degrees  of  program  reusability  to  be 
specified  in  transitioning  MCCR  applications 
to  the  Ada  language.  Composition  ortho¬ 
gonality  is  important  because  many  Ada 
features  that  facilitate  program  reusability 
have  been  avoided  or  unavailable  in  past 
MCCR  application  software  that  have  com¬ 
monly  relied  upon  simple  constructs  with 
predictable  performance  efficiency  (Bassman 
et  al  1985).  In  addition,  dependencies  on  the 
implementation  of  the  Ada  RTS  to  imitate 
low-level  control  of  processing  resources  can 
thwart  strong  reusability  achieved  through 
composition  orthogonality. 

In  managing  the  transition,  software 
reuse  should  be  safeguarded  by  balancing 
program  reusability  with  performance  during 
the  design  phase.  Furthermore,  reusable  Ada 
software  components  will  be  facilitated  by 
language  implementations  that  are  guided  by 
the  specification  of  classes  of  Ada  Virtual 
Machines  for  MCCR  applications  and  practi¬ 
cal  restrictions  on  Appendix_F  of  the  Ada 
RM.  This  would  increase  the  likelihood  of 
formally  certifying  the  degree  of  reuse  for 
software  components  (Cohen  1985). 
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COSMIC  —  NASA’s  Software  Distribution  Center 


John  A  Gibson 
COSMIC 

Computer  Services  Annex 
University  of  Georgia 
Athens,  GA  30602 

Abstract 


NASA  and  the  University  of  Georgia  established  the  Computer  Software  Management  and 
Information  Center  (COSMIC)  to  collect  and  disseminate  computer  software  developed  by  NASA  and 
its  contractors.  The  current  COSMIC  inventory  of  over  1100  programs  is  available  for  business, 
industry,  educational  institutions,  and  government. 


Text 

The  Computer  Software  Management 
and  Information  Center  (COSMIC)  was  es¬ 
tablished  by  NASA  and  the  University  of 
Georgia  in  1966  to  function  as  a  software  col¬ 
lection  center  and  to  provide  dissemination 
service  for  computer  software  developed  by 
NASA  and  its  contractors.  COSMIC  has 
received  and  processed  nearly  5000  computer 
programs  since  its  beginning.  Currently  over 
1100  programs  in  the  inventory  are  supplied 
to  business,  industry  and  educational  institu¬ 
tions  as  well  as  to  other  government  agen¬ 
cies.  Programs  are  priced  at  a  fraction  of 
their  original  development  costs. 

Each  new  computer  program  and  docu¬ 
ment  and  each  update  received  from  NASA 
and  NASA  contractors  is  screened  and 
evaluated  for  completeness  and  application 
potential  before  being  added  to  the  inventory. 
This  process  involves  checking  for  syntactical 
accuracy  through  compilation  and/or  assem¬ 
bly  on  a  host  of  systems  available  at  the 
University  of  Georgia.  Each  program  is 
assigned  appropriate  subject  category  codes 
and  index  terms  before  an  abstract  is 
prepared  and  the  program  is  made  available 
to  the  public. 

The  software  submitted  to  COSMIC 
reflects  the  varied  activities  of  NASA  which 
involve  basic  research  and  development  pro¬ 
jects  as  well  as  projects  directly  related  to 
space  missions.  Software  developed  in  such 
areas  as  structural  mechanics,  computer 


graphics,  mathematics,  communications,  and 
thermodynamics  broaden  the  scope  of  pro¬ 
grams  in  the  inventory.  Many  of  these  pro¬ 
grams  can  be  directly  applied  to  secondary 
use  with  little  or  no  modification.  Other  pro¬ 
grams  can  be  adapted  for  a  very  specific  pur¬ 
pose  at  substantially  less  than  the  cost  of 
developing  a  new  program.  COSMIC  sup¬ 
plied  the  source  code  with  each  program  so 
that  its  capabilities  can  be  modified  or 
extended  as  needed. 

The  COSMIC  customer  service  staff 
provides  assistance  to  users  in  locating  pro¬ 
grams  or  groups  of  programs  that  best  meet 
the  user’s  needs.  This  customized  search  by 
the  COSMIC  staff  is  provided  at  no  charge  to 
the  user.  The  COSMIC  staff  is  trained  to 
assist  users  in  locating  software  and  will  assist 
in  locating  specific  public  domain  software 
packages  even  if  they  are  not  part  of  the 
COSMIC  inventory.  For  users  who  have  a 
general  interest  in  software  or  for  broad 
application  needs,  COSMIC  publishes  the 
COSMIC  Software  Catalog.  This  annual  pub¬ 
lication  is  a  comprehensive  collection  of  pro¬ 
gram  abstracts,  organized  into  75  subject 
categories  and  includes  a  keyword  index  and 
an  author  index  to  aid  in  the  location  of  pro¬ 
grams. 

Our  users  provide  the  best  examples  of 
how  NASA  software  is  used.  These  exam¬ 
ples  include:  1)  using  the  application  package 
essentially  as-developed  for  a  similar  applica¬ 
tion  in  industry,  2)  converting  the  application 


package  to  operate  on  a  different  machine,  3) 
and  taking  related  routines  from  one  package 
and  applying  these  routines  in  a  different 
package.  COSMIC’s  service  includes  distri¬ 
bution  of  programs  and  documents  between 
NASA  centers,  so  our  users  include  many 
NASA  staff  members.  Approximately  25% 
of  COSMIC’s  distribution  involves  the 
transfer  of  software  to  NASA  centers  and 
contractors  for  reuse  on  NASA  projects. 

In  20  years  of  experience  operating 
NASA’s  software  distribution  center, 
COSMIC  has  had  many  opportunities  to 
learn.  The  lessons  we  have  learned  cover 
many  of  the  items  mentioned  in  the 
workshop  announcement  letter  under  "library 
experience"  and  "logistics  of  reuse".  The  best 
advice  I  can  give  your  library  committee  is  to 
keep  the  number  of  rules,  directives,  restric¬ 
tions  and  paper  work  to  a  minimum.  Make  it 
easy  to  put  programs  into  your  library.  Make 
sure  that  your  staff  will  be  friendly  and  help¬ 
ful  in  locating  software  for  a  user.  Make  sure 
you  have  an  efficient  system  for  transmitting 


the  software  to  the  user.  Do  all  your  screen¬ 
ing,  testing,  quality  assurance,  performance 
measurements,  etc.,  before  the  software 
officially  becomes  available  from  the  library. 
Define  the  technical  or  user  support  available 
for  each  item  in  the  inventory.  Last,  but  not 
least,  obtain  information  from  users  that 
reflect  the  benefits  they  realized  from  using 
the  software. 

The  actual  utilization  of  the  library  as  a 
place  to  submit  software  as  well  as  a  place  to 
obtain  software  will  depend  on  your  ability  to 
market  your  services.  Our  experience  shows 
that  this  effort,  both  to  obtain  software  and 
to  promote  the  use  of  software,  is  a  continu¬ 
ing  effort  that  involves  significant  resources 
of  staff  time  and  money. 

The  concept  of  a  single  source  of  com¬ 
puter  software,  whether  routine  or  application 
packages,  is  not  new.  NASA  has  20  years 
experience  in  operating  such  a  facility, 
COSMIC,  at  the  University  of  Georgia. 
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NASA 

National  Aeronautics  and 
Space  Administration 


"The  aeronautical  and  space  activities  of  the  United  States  shall  be 
conducted  so  as  to  contribute  ...  to  the  expansion  of  human  knowl¬ 
edge  of  phenomena  in  the  atmosphere  and  space.  The  Administration 
shall  provide  for  the  widest  practicable  and  appropriate  dissemination 
of  information  concerning  its  activities  and  the  results  thereof.  " 
-NATIONAL  AERONAUTICS  AND  SPACE  ACT  OF  1958 


COSMIC  ACTIVITIES 


1.  Technical  Screening 

2.  Promotions 

3.  Order  Processing 

4.  User  Support 

5.  NASTRAN  Maintenance 

6.  Benefits  Analysis 
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HARDWARE  AVAILABLE  FOR  PROGRAM  CHECKOUT 


CDC  CYBER  205 


CDC  CYBER  845 
CDC  CYBER  850 
IBM  3081 
DEC  VAX  11/780 
UNIVAC  90/80 
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DOCUMENTATION  REQUIREMENTS 


Problem  /  Function  Definition 


Method  of  Solution 
User  Instructions 
Implementation  Instructions 
Sample  Input  /  Output 
Environmental  Characteristics 
Other  Appropriate  Information 


CLASSIFICATION  OF  PROGRAMS 

\  Excellent  quality  program.  Qualifies 

as  Tech  Brief.  Must  be  NASA  funded. 

II  Program  and  documentation  meet 
publication  standards. 

III  Programs  returned  to  the  submittal  site. 

IV  Programs  and  documentation  which  are 

incomplete  and  additional  information 
has  been  requested. 
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Machine  independence  and  /  or  vintage 
Level  of  programming  or  maintenance  support 
Quality  of  supporting  documentation 
Program  sales  potential  or  history 
Program  functionality 
Program  size 
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SOFTWARE  COMMONALITY 
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Norman  S.  Nise 
Chuck  Griffin 

Rockwell  International 

Abstract 


This  paper  discusses  the  design  of  software  packages  to  improve  their  degree  of  reusability.  The 
degree  of  commonality  both  across  applications  areas  and  within  applications  areas  are  tied  together  to 
form  a  commonality  matrix  against  which  software  packages  can  be  measured  for  potential  reuse. 
Further,  design  techniques  to  improve  commonality  are  explored.  Emphasis  is  placed  upon  designing 
software  with  the  widest  domain  of  applicability  in  order  to  realize  the  financial  benefits  of  reusable 
software. 


Introduction 

By  now  it  is  a  well  known  fact  that  the 
demand  for  software  is  increasing  dispropor¬ 
tionately  to  the  supply.  More  specifically,  the 
demand  is  increasing  at  a  12%  rate  compared 
to  an  increase  of  only  8%  for  software  supply. 
The  problem  is  exacerbated  by  the  fact  that 
software  costs  are  also  rising  •  astronomically. 
The  United  States  Department  of  Defense 
estimates  that  software  costs  will  rise  to  $32 
billion  per  year  from  a  modest  $2.5  billion  in 
1980. 

Software  development  methods  have 
contributed  to  the  software  economic  prob¬ 
lem  through  maintenance  costs  that  represent 
50  to  80  percent  of  the  total  cost  while  design 
and  development  are  only  20  to  50  percent  of 
the  cost.  These  methods  have  also  resulted 
in  code  that  is  difficult  to  modify,  contains 
errors,  and  is  produced  with  low  productivity. 

The  DOD  and  its  Software  Technology 
for  Adaptable  Reliable  Systems  (STARS)  ini¬ 
tiative  have  already  begun  to  study  ways  to 
alleviate  the  above  described  problems. 

One  promising  solution  to  the  software 
problem  is  reusable  software.  Reusable 
software  includes  reusable  requirements, 
specifications,  design,  code,  documentation, 
etc.  It  can  be  used  between  applications  with 
little  or  no  modification.  It  can  be  imported 

*  Ada  is  a  registered  trademark  of  the  United 
States  DOD,  Ada  Joint  Program  Office. 


and  used  as  part  of  a  larger  project.  Reusable 
software  will  cause  a  reduction  in  manhours 
required  for  the  design,  development,  testing 
and  maintenance  of  software. 

Two  major  factors  have  prevented  the 
idea  of  reusable  software  from  becoming  a 
reality.  The  first  was  the  proliferation  of 
computer  languages.  It  would  have  been  a 
difficult  task  to  keep  and  catalogue  software 
over  the  domain  of  many  languages.  With 
the  development  of  Ada*  along  with  the 
DOD’s  decree  that  Ada  will  be  the  higher 
level  language  for  all  embedded  systems,  the 
outlook  for  the  future  is  a  single,  widely-used 
language  that  can  be  used  to  develop  and  use 
reusable  packages.  Ada  itself  was  designed  to 
be  used  for  the  development  of  reusable 
packages. 

The  second  factor  has  been  proprietary 
interests  on  the  part  of  software  developers. 
There  was  the  fear  of  not  realizing  maximum 
profits  if  software  was  shared  among  other 
members  of  the  industrial  community. 
Developed  software  was  hidden  and  not 
shared.  STARS  is  now  looking  into  this 
problem  by  trying  to  establish  incentives  to 
develop  and  use  reusable  software. 

We  can  envision,  some  time  in  the 
future,  a  reusable  software  library  where 
software  "parts”  are  cataloged  and  available 
for  use  within  larger  programs. 


Commonality 

One  of  the  factors  that  will  determine 
the  success  of  a  library  package  will  be  the 
degree  of  reuse.  The  more  times  a  software 
package  is  used,  the  more  we  can  rely  on  a 
reusable  software  system  to  solve  the 
economic  problems  previously  described. 
The  degree  of  reuse  depends  upon  the 
domain  of  applicability  of  that  software.  That 
is  to  say,  can  that  software  package  be 
depended  upon  to  be  used  many  times?  If 
the  software  has  wide  applicability,  either 
across  many  different  applications  or  wide 
applicability  within  a  single  application,  the 
answer  probably  will  be  affirmative. 

The  amount  of  reuse  to  which  a  module 
is  put  through  is  dependent  upon  letting  the 
user  know  of  its  existence  and  the  domain  of 
its  applicability.  Thus,  it  will  be  important 
for  the  designer  of  the  package  to  give  to  that 
package  the  attribute  of  maximum  applicabil¬ 
ity  and  properly  classify  that  package  as  to  its 
range  of  application.  Again,  the  designer 
must  not  only  build  the  attribute  of  wide 
applicability  into  the  package,  but  also  must 
communicate  this  attribute  to  the  user  of  the 
library. 

It  is  obvious  that  several  pitfalls  can  be 
encountered  that  will  diminish  the  economic 
benefit  to  be  accrued  from  the  use  of  reus¬ 
able  software. 

(1)  wide  applicability  is  built  into  the  A 
package  but  that  attribute  is  not  com¬ 
municated  to  the  user  through,  the 
library  classification  system, 

(2)  a  package  is  designed  that  has  wide 
applicability  over  a  narrow  field  of  appli¬ 
cations  but  could  have  been  designed  to 
cover  other  application  areas, 

(3)  a  package  is  designed  that  has  narrow 
applicability  but  could  have  been 
designed  to  have  wider  applicability 
either  over  a  single  applications  area  or 
over  many  applications  areas. 

Thus  proper  design  and  classification  up 
front  is  imperative.  Narrowing  of  the  field  of 
applicability  will  lead  to  the  proliferation  of 
modules  with  the  resulting  increase  in  cost 
along  with  the  unnecessary  complication  of 
the  reusable  software  retrieval  system.  More 


software  will  exist  and  maintenance  costs  will 
increase. 

If  a  software  package  is  classified  as 
application  specific,  the  likelihood  of  the 
package  being  applied  outside  of  that  domain 
will  be  small.  For  example,  software 
classified  as  being  in  the  domain  of  account¬ 
ing,  will  be  used  only  for  accounting.  That 
package  will  not  be  used  for  missile  systems. 
If  the  package  contained  sort  routines  that 
could  be  used  outside  of  the  domain  of 
accounting,  the  savings  would  not  be  realized 
in  this  case. 

As  reusable  software  libraries  are  es¬ 
tablished  it  is  imperative  that  software  placed 
into  these  libraries  be  designed  with  as  large 
a  domain  of  applicability  as  possible. 

For  example,  a  routine  to  add  two 
objects  together  could  be  very  specific  and  be 
applicable  only  to  integer  numbers.  Other 
packages  would  then  have  to  developed  for 
floating  point  numbers,  fixed  point  numbers 
and  the  like.  Each  package  will  have  dimin¬ 
ished  reuse  and  each  package  will  multiply 
the  costs  of  development  and  maintenance. 
We  cannot  overemphasize  the  fact  that 
library  package  development  use  every  tech¬ 
nique  possible  to  extract,  up  front,  from  a 
package  the  maximum  amount  of  reuse.  To 
assume  application  specificity  when  in  reality 
wide  domain  applications  can  be  obtained  is 
to  defeat  the  gain  to  be  realized  from  reus¬ 
able  software. 

Let  us  first  take  a  look  at  a  classification 
system  to  describe  the  commonality  of 
software  parts. 

Classification  System  for  Commonality 

Application  software  reuse  can  be  mea¬ 
sured  across  two  domains: 

(1)  within  an  application  area 

(2)  across  application  areas 

By  applications  area  we  mean  a  distinct 
industrial  grouping.  For  example,  different 
applications  areas  could  include  missiles,  air¬ 
craft,  spacecraft,  weapons,  ships,  lasers, 
command/control,  radar,  etc. 

Software  that  fulfills  a  high  degree  of 
reuse  in  any  of  the  above  domains  is  a  good 


candidate  for  reusable  software.  Since  our 
objective  is  to  design  software  packages  that' 
will  yield  the  maximum  amount  of  reuse,  the 
design  process  should  explore  the  possibility 
of  expanding  a  package  designed  for  a  specific 
applications  are  to  a  package  that  is  reused 
across  many  applications  areas.  Again,  the 
cost  of  not  looking  carefully  into  this  possi¬ 
bility  and  filling  a  reusable  software  library 
with  an  excess  of  application  specific  software 
packages  could  cancel  some  of  the  benefits 
that  would  accrue  to  a  reusable  software  sys¬ 
tem. 

We  can  then  think  of  commonality  matrix 
that  has  two  dimensions: 

(1)  degree  of  commonality  across  applica¬ 
tion  areas 

(2)  degree  of  commonality  within  an  appli¬ 
cations  area 

This  matrix  is  shown  in  Figure  1.  Each 
square  of  the  matrix  suggests  a  relative  value 
for  software  package  commonality.  The 
higher  the  index,  the  greater  the  domain  of 
applicability  that  is  predicted.  The  scale  goes 
from  0  to  6  with  0  yielding  the  least  com¬ 
monality  and  6  yielding  the  most. 

As  an  example.  Figure  2  suggests  a  pos¬ 
sible  classification  of  software  for  a  spacecraft 
application  specific  area.  This  classification 
then  classifies  the  given  software  according  to 
the  vertical  direction  of  Figure  1.  In  Figure  3 
the  same  software  packages  are  classified 
according  to  the  horizontal  direction  of  Fig¬ 
ure  1.  If  we  locate  the  intersection  of  each 
package  on  Figure  1,  we  can  determine  the 
commonality  index.  We  now  list  each  pack¬ 
age  and  its  commonality  index: 

sorts . 6 

data  structures . 6 

abstract  processes . 6 

computer  system . 6 

s/w  maintenance . 6 

math  functions . 5 

geometric  functions.. ..5 

matrix  functions . 5 

vector  functions . 5 

process  functions . 5 

communications . 5 

guidance  functions . 4 

navigation 

teiemetric  functions.. .4 


s/w  design . 4 

s/w  development . 4 

s/w  verification . 4 

mission  functions . 2 

input  routines . 2 

output  routines . 2 

system  functions . 0 

warhead  control . 0 

system  inputs . 0 

system  output . 0 


This  matrix  can  be  used  then  to  orient 
us  in  the  design  of  reusable  packages.  Our 
design  objective  is  to  improve  the  packages’ 
commonality  index.  Let  us  now  take  a  look 
at  techniques  that  can  help  us  meet  our  goal 
of  increasing  a  pacxages’  commonality  index. 

Reusable  software  will  be  designed 
using  Ada  with  its  attributes  of  information 
hiding,  modularity,  and  generic  packages.  In 
order  to  improve  the  commonality  index  of 
an  Ada  software  package,  we  want  to  strip 
away  those  parts  of  the  package  that  contrib¬ 
ute  to  a  narrow  degree  of  applicability.  Fig¬ 
ure  4  shows  a  package  divided  into  its  appli¬ 
cation  specific  parts  and  its  application 
independent  parts.  Here  we  are  dividing  the 
package  into  three  main  divisions;  (1)  input, 
(2)  process,  (3)  output. 

We  can  assume  that  the  package  of  Fig¬ 
ure  4  would  not  be  a  good  candidate  for  reus¬ 
able  software  across  application  boundaries 
because  of  the  application  dependent  parts. 
If  the  application  dependent  parts  are 
removed,  the  remainder  of  the  package  could 
possibly  be  engaged  in  heavy  reuse. 

Two  ways  exist  to  solve  this  problem. 
The  first  way  would  be  to  create  application 
dependent  packages  consisting  solely  of  the 
application  dependent  parts  of  the  original 
package.  This  concept  is  shown  in  Figure  5. 
This  technique  would  create  two  library  pack¬ 
ages.  One  package  would  have  a  high  degree 
of  commonality  and  reuse  while  the  other 
package  would  have  a  low  degree  of  com¬ 
monality  and  reuse. 

A  second  technique  would  be  creation 
of  generic  packages  that  would  be  instantiated 
with  the  application  dependent  parts  as  shown 
in  Figure  6.  Here  the  only  library  package  is 


the  generic  packages.  The  generic  packages 
would  have  the  most  reuse  across  applica¬ 
tions  boundaries.  The  instantiator  is  not  a 
library  package,  but  rather  is  a  software 
module  created  for  an  application  specific 
function.  Its  reuse  would  not  be  great  and  it 
would  not  be  placed  into  the  reusable 
software  library. 

Figure  6  shows  the  input,  process,  and 
output  within  the  same  package.  It  might  be 
preferable  to  keep  the  input,  process,  and 
output  in  separate  and  distinct  packages.  For 
this  case,  the  instantiator  procedure  would 
require  sequencing  in  order  to  instantiate  the 
input,  process,  and  output  packages  in  the 
proper  order. 

Example 

As  an  example,  consider  the  software 
represented  in  Figure  7.  This  software 
checks  inputs  for  limits,  ranges,  and,  in  the 
case  of  discrete  inputs,  desirable  states.  The 
outputs  from  the  software  are  various  mes¬ 
sages  along  with  scaled  inputs. 

This  module  thus  contains  much  in  the 
way  of  application  specific  software  and 
tables.  It  contains  limits,  scale  factors,  mes¬ 
sages,  and  the  like.  This  package  would  not 
be  considered  to  be  reusable.  Why,  every 
application  would  require  a  reconfiguration. 

In  order  to  make  this  package  reusable, 
the  non-generic  parts  can  be  removed.  A 
generic  module  that  does  the  checking,  scal¬ 
ing  and  data  output  can  be  writrten.  The 
reusable  module  would  contain  just  the  pro¬ 
cess.  The  data  can  be  acquired  from  other 
modules  that  are  application  specific. 

Figure  8  shows  the  generic  module 
used  for  checking,  scaling,  and  the  outputting 
of  messages  and  scaled  data.  Other  applica¬ 
tion  specific  modules  handle  conversion  to 
common  data  types  and  contain  tables  of 
ranges,  limits,  scale  factors,  and  messages 
along  with  tables  formed  from  the  converted 
inputs.  In  Figure  8,  modules  1  and  2  would 
not  be  reusable,  but  module  3  would. 
Modules  I  and  2  could  be  contained  within 
the  instantiator.  Module  3  now  can  be  used 
over  a  wide  range  of  applications  where  range 
and  limit  checking  are  done. 


This  example  shows  that  with  proper 
design,  reusable  modules  can  be  created  from 
non-reusable  modules  by  separating  the  appli¬ 
cation  specific  parts  and  creating  generic  reus¬ 
able  modules. 

Summary 

This  paper  has  presented  several  con¬ 
cepts  relating  to  the  design  of  software  pack¬ 
ages  with  the  attribute  of  high  reusability. 
Specifically,  we  showed  that  the  degree  of 
commonality  of  a  module  must  be  measured 
both  within  a  specific  applications  area  and 
across  many  application  areas.  A  matrix  was 
present**'*  with  which  to  evaluate  the  com¬ 
monality  of  modules  across  both  domains. 

Two  techniques  were  presented  for 
improving  the  commonality  of  software  pack¬ 
ages.  The  first  technique  suggests  separating 
application  dependent  parts  from  application 
independent  parts.  The  application  indepen¬ 
dent  part  becomes  a  reusable  package. 

The  second  technique  creates  a  generic 
package  that  is  instantiated  with  application 
dependent  parameters.  The  generic  package 
becomes  the  reusable  software  package  while 
the  instantiator  is  developed  for  each  applica¬ 
tion  and  is  not  a  reusable  software  package. 
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Figure  2  -  Classification  of  Commonality. 
Example  Spacecraft  Specific. 
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Figure  3  -  Classification  of  Commonality. 
Example  Across  Applications. 
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Figure  4  -  Software  Package  Containing  Application  Parts 


Figure  5  -  Packages  Separated  Into  Application  Independent 
and  Application  Dependent 
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Figure  6  -  Figure  Application  Dependent  Parts  Created  from 
Instantiation  of  Generic  Packages 
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Slide  1:  The  Software  Environment 

Software  System  Size/Complexity  -  many  of 
the  current  Army  systems  contain  software 
with  hundreds  of  functions  are  hundreds  of 
thousands  of  lines  of  source  code.  To  manu¬ 
ally  analyze  this  volume  of  software  would  be 
extremely  labor  intensive. 

Software  Costs  -  Software  often  takes  the  lion 
share  of  the  system  cost  because  software 
development  is  so  labor  intensive.  Software 
maintenance  can  account  for  as  much  as  75% 
of  the  Life  cycle  cost. 

Proliferation  of  languages/dialects  -  It  is 
estimated  that  there  are  450  software 
languages  in  existence;  even  though  Ada  is 
suppose  to  be  the  cure-all  and  be  the 
language  for  embedded  systems  applications, 
our  experience  has  shown  that  a  sizable  per¬ 
centage  of  the  450  languages  are  currently 
used  by  DoD  in  the  systems  we  test. 

Compliance  with  design  methodologies/ 
development  standards  -  We  are  all  con¬ 
cerned  that  the  software  being  developed  for 
our  applications  complies  with  good  design 
methodologies  (such  as  top  down  design  and 
structured  programming)  and  good  develop¬ 
ment  standards  (such  as  DoD-STD-2167). 
we  check  and  verify  compliance? 

Slide  2:  Systems  Requiring  Assessment 

Back  in  April  1984,  we  took  a  look  at 
the  systems  on  which  we  were  performing 
software  testing  or  planning  for  software  test¬ 
ing.  This  slide  shows  whose  systems  and  the 
languages  the  software  was  written  in. 

Slide  3:  Language  Processors  Required 

This  slide  shows  the  languages  of  the 
previous  slide  ordered  by  High  Order 
Language  (HOL)  and  Assembler  (ASM).  To 
prepare  automated  tools  to  analyze  software 
written  in  each  of  these  languages  would  be 
very  expensive.  To  manually  analyze  the 
software  requires  individuals  familiar  with 


each  of  these  languages  and  would  also  be 
very  labor  intensive.  The  number  of 
languages  with  which  we  were  bombarded, 
led  us  to  develop  an  automated  tool  which, 
with  a  relative  small  effort,  could  analyze 
software  written  in  a  new  language. 

Slide  4:  MSAT  History 

This  slide  shows  the  tools  which  led  up 
to  the  MSAT  effort.  It  started  with  the  Pro¬ 
gram  Flow  Analyzer  (PFA)  back  in  the  late 
70’s  and  early  80’s.  During  83  and  84,  we 
developed  specific  tools  for  specific  systems; 
but  since  they  were  written  for  specific  sys¬ 
tems  and  contained  little  documentations 
they  are  not  reusable.  During  84  and  85,  we 
developed  a  FORTRAN  Code  Analysis  Pro¬ 
gram  (FCAP),  a  table  driven  Assembler 
Code  Analysis  Program  (ACAP)  and  a  C 
Code  Analysis  Program. 

These  are  better  documented  and  somewhat 
more  general  purpose  in  nature.  However, 
they  were  just  stop-gap  measures  in  prepara¬ 
tion  of  the  general  purpose  tool  -  MSAT  - 
which  we  are  finishing  the  acceptance  testing 
in  April  86.  The  languages  shown  are 
languages  which  we  have  analyzed  wuh  one 
of  the  tools.  The  systems  shown  are  systems 
which  have  had  some  of  their  software 
analyzed  with  one  of  the  tools  (not  all  results 
from  these  analyses  have  been  included  in 
formal  test  reports  or  the  respective  systems. 

Slide  5:  Development  Philosophy 

In  developing  MSAT  our  development 
philosophy  included  the  following  items:  We 
wanted  MSAT  to  be  language  table  driven. 
We  chose  to  use  a  Commercial  Data  Base 
Management  System  (DBMS)  (INGRES)  in 
order  to  minimize  development  costs  and  to 
take  advantage  of  the  many  useful  features  of 
a  commercial  DBMS.  We  wanted  MSAT  to 
be  user  friendly,  e.g.,  menu  driven  with  lots 
of  help.  We  knew  that  MSAT  was  not  ini¬ 
tially  going  to  be  the  ultimate  tool,  so  we 


designed  it  for  expansion  and  enhancement. 
We  decided  that  we  should  practice  what  we 
preach  so  we  fully  documented  MSAT  (we 
followed  DoD-STD-2167,  draft  standard  at 
the  time  we  started)  and  we  even  plan  on 
running  MSAT  on  itself  to  prove  its  quality 
and  maintainability.  We  are  validating  the 
tool  and  the  test  plans,  procedures  and 
results  are  being  reviewed  by  other  Army 
organizations.  We  plan  on  maintaining 
configuration  control  of  MSAT  for  many 
years. 

Slide  6:  Static  Analysis  Functions 

This  slide  shows  the  IS  static  analysis 
functions  as  delineated  in  the  National 
Bureau  of  Standards  (NBS)  document:  a  tax¬ 
onomy  of  tool  features  for  the  Ada  program¬ 
ming  support  environment.  The  initial 
implementation  of  MSAT  contains  features 
in  the  following  areas:  Auditing,  Complexity, 
Statistical  Analysis,  Interface  Analysis,  Com¬ 
parison,  Error  checking  and  Structure  Check¬ 
ing. 

Auditing  -  comparing  collected  metrics  to 
standards,  e.g.  from  DoD-STD-1679  #  Exe¬ 
cutable  Statements  —  200. 

Complexity  -  McCabes  Cyclomatic  Complex¬ 
ity  and  Meyer’s  Extension 

Statistical  Analysis  •  Various  simple  statistics 
on  the  code  metrics 

Interface  Analysis  -  Does  the  call  statement 
with  parameters  match  the  called  routine  with 
its  parameters 

Comparison  -  Compares  two-  version  for 
structure  changes,  metric  changes,  etc. 

Error  Checking  -  various  errors  such  as 
unresolved  external  references 

Structure  Checking  -  Recursion,  Lower  level 
module  calling  higher  module 

The  Remainder  of  the  functions  should  be 
added  in  the  future. 

Slide  7:  MSAT  Schematic 

This  schematic  shows  that  MSAT  runs 
on  VAX  with  VMS.  A  tape  of  the  source 
code  (in  ASCII)  is  entered  onto  disk.  This 
source  code  is  entered  into  the  automatic 
Language  processor  which  extracts  the  basic 
metrics  and  stores  away  the  info  into  the  data 
base.  The  Static  analysis  function  take  the 


metrics  from  the  data  base  and  provides  the 
various  analyses  and  stores  the  results  back 
into  the  data  base.  The  report  generator 
takes  the  info  from  the  data  base  to  create 
the  desired  reports. 

Slide  8:  MSAT  Data/Control  Flow 

This  slide  provides  a  more  detailed  look 
of  the  data  and  control  flow.  It  should  be 
noted  that  the  source  code  is  entered  into  the 
automatic  language  processor  along  with  the 
source  Language  description.  For  the  static 
analysis  the  user  can  enter  his  own  software 
standards  to  compare  against  the  default  stan¬ 
dards  in  the  data  base  which  are  based  upon 
DoD-STD-2167,  1679. 

Slide  9:  MSAT  Operational  Capability 

This  slide  shows  the  MSAT  initial  capa¬ 
bility.  The  first  language  capability  is  VAX 
FORTRAN  and  8085  Assembler.  VAX 
FORTRAN  was  chosen  because  MSAT  is 
written  in  VAX  FORTRAN  and  we  wanted 
to  check  the  quality  of  the  MSAT  code  itself. 
(MSAT  also  has  the  embedded  query 
Language  EQUEL  for  INGRES).  MSAT  is 
able  to  handle  3  languages  for  each  system 
and  2  for  any  unit  or  subroutine.  In  a  partic¬ 
ular  unit  MSAT  can  analyze  the  code  for  a 
situation  where  there  is  embedded  assembly 
language  over  the  Static  Analysis  (SA)  func¬ 
tions.  The  reports  are  described  in  greater 
detail  on  the  next  slide. 

Slide  10:  MSAT  Reports 

This  slide  shows  the  general  break¬ 
down  of  the  MSAT  reports. 

Source  Listing/Table  of  Contents  -  We  some¬ 
times  get  boxes  of  code  listings  where  a  table 
of  contents  would  come  in  very  handy. 

Software  quality  metric  reports  -  This  shows 
the  various  levels  of  the  quality  metric 
reports. 

Structure  Chart  -  This  shows  the  subroutine 
hierarchical  call  structure 

Error  Report  -  Shows  various  errors  detected 
i.e.,  Unresolved  external  references. 

Interface  Analysis  Report  -  Potential  prob¬ 
lems  in  how  the  calling  and  called  routines 
match  up. 


Standards  Compliance  -  Shows  the  various 
levels  of  this  reports  exception  (those  units 
not  complying),  unit  summary,  and  system 
summary. 

Change  analysis  report  -  the  differences 
between  two  versions  of  the  same  system; 
shows  differences  in  the  metrics  on  a  unit  by 
unit  basis  as  well  as  differences  in  system 
structure.  This  is  useful  to  handle  the  tape- 
of-the-month  syndrome  where  we  test  a  sys¬ 
tem,  we  find  problems,  the  contractor  goes 
back  to  his  place  and  comes  back  with  a  new 
version  of  the  software  to  be  installed.  What 
did  he  change?  This  will  help  point  where 
and  what  kind  of  changes  have  been  made. 

Slide  11:  Sample  report 

This  is  a  sample  of  MS  AT  Standards 
Compliance  Unit  Summary  Report.  It  shows 
for  example  that  the  standard  of  executable 
Statements  less  than  or  equal  to  200  is  met 
by  all  203  units.  The  next  standard,  Max¬ 
imum  consecutive  lines  of  code  without  com¬ 
ments  less  than  or  equal  to  10  is  met  by  192 
or  94.6%  of  the  units  and  not  met  by  11 
units.  The  value  10  in  the  standard  can  be 
changed  to  S  by  the  user  if  so  desired. 

Slide  12:  Software  Life  Cycle  Costs 

Assume  that  a  software  system  during 
the  initial  project  development  cost  $3M  (as 
depicted  by  the  solid  line).  Over  the  total 
life  cycle  of  the  system  (10‘ years)  the  total 
software  costs  could  total  S10M,  with  S7M 
being  spent  for  maintenance  where  mainte¬ 
nance  is  defined  as  fixing  bugs  and  enhancing 
the  system.  Studies  have  shown  that  up  to 
75%  of  the  software  life-cycle  costs  can  be 
spent  on  maintenance.  Conversely,  the 
dashed  line  depicts  a  system  where  we  may 
have  spent  more  money  up  front  on  docu¬ 
mentation  and  using  tools  such  as  MSAT  but 
the  total  life  cycle  costs  should  be  decreased. 

Slide  13:  The  Multi-Lingual  Static  Analysis 
Toc»  (MSAT) 

This  is  an  overview  slide  to  refresh  our 
memories  as  to  what  MSAT  does.  First, 
MSAT  provides  static  analysis  of  the  software 
in  the  areas  we  have  already  talked  about. 
Second,  MSAT  provides  a  quality  analysis  of 


the  code,  i.e.,  how  good  is  the  quality  of  the 
code.  Third,  it  provides  visibility  into  the 
code  to  assist  or  analysis  in  understanding 
and  analyzing  the  code.  Finally,  MSAT  pro¬ 
vides  a  comparison  between  various  version 
to  show  what  has  actually  been  changed  and 
where. 

Slide  14:  Anticipated  MSAT  Users 

Software  Developers  -  we  would  like  to 
give  MSAT  to  software  developer  to  be  used 
during  development  •  no  reason  to  check  the 
code  after  the  development  is  complete,  find 
problems  and  the  developer  says,  OK  there 
are  problems,  now  pay  me  to  fix  them. 
Much  better  to  give  it  to  developer  to  be 
used  during  development  so  problems  can  be 
changed  up  front. 

Verification  and  validation  teams  or  contrac¬ 
tors  -  obvious  usage 

Development  testers  -  that  us  (EPG)  can  be 
used  during  DT. 

Users  -  the  Irtel  School  was  interested  in 
MSAT  to  help  them  analyze  a  program  they 
had  gotten  from  Great  Britain  to  understand 
the  source  and  algorithms. 

Software  Support  Centers  -  the  LCSSC  could 
use  MSAT  for  maintenance  quality 
assurance. 

Software  Libraries  -  STARS  is  interested  in 
MSAT  to  be  used  to  analyze  the  reusable 
Ada  components  which  will  be  placed  in  the 
reusable  components  library. 

Slide  15:  Future  Development  Proposed  to 
STARS 

The  first  thing  is  to  develop  the  initial 
capability  to  analyze  Ada  code.  Second,  we 
need  to  make  MSAT  transportable  so  it  can 
be  more  usable.  To  do  this  we  propose 
rewriting  MSAT  .n  Ada  (everybody  should 
eventually  have  an  Ada  compiler),  eliminat¬ 
ing  the  VAX/VMS  dependencies  (system 
calls,  etc.)  and  providing  a  stand-alone, 
government  owned  DBMS  so  that  none  has 
to  buy  the  commercial  DBMS. 

Third,  we  need  to  enhance  the  Ada 
capability  to  handle  the  Ada  special  charac¬ 
teristics  such  as  concurrent  processing. 


exception  handling.  Fourth,  develop  a  library 
language  capabilities:  pick  the  20  most  used 
languages  in  DoD  and  make  MSAT  work  on 
them. 

Fifth,  expand  the  current  static  analysis 
capability  in  all  IS  areas  shown  before. 
Finally,  provide  the  capability  to  store  and 
report  on  manually  collected  data  such  as 
software  trouble  reports  associated  with  the 
software  system. 


Slide  16:  FY86  MSAS  Goals 

If  MSAS  is  funded  by  STARS  by  April 
1,  the  initial  Ada  capability  would  be 
developed,  we  would  pick  another  language 
such  as  Pascal  and  provide  the  capability  to 
analyze  software  written  in  that  language. 
And  finally,  we  would  begin  converting 
MSAS  to  Ada  to  make  it  transportable. 
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Introduction 

Software  reuse  in  the  context  of  this 
paper  is  the  selection,  modification  and  adap¬ 
tation  necessary  to  fit  an  existing  component 
into  a  new  software  system.  The  focus  of  the 
paper  is  on  the  selection  problem,  i.e,  the 
ability  to  locate  and  retrieve  an  appropriate 
component  from  a  large  collection  of  com¬ 
ponents,  such  as  collection  of  Ada  libraries. 

A  classification  scheme  is  a  domain 
knowledge  structure  that  organizes  collections 
of  items  to  satisfy  the  needs  of  the  users  of 
the  collections.  The  GTE  Reusability  project 
has  performed  an  in-depth  investigation  on 
classification  schemes  with  the  aim  of  identi¬ 
fying  and  adapting  one  that  satisfies  the 
needs  of  software  users.  In  this  paper  a 
faceted  classification  scheme  is  proposed. 
The  classes  in  the  scheme  are  identified  by 
collecting  descriptive  terms  from  component 
descriptions  and  grouping  them  by  their  rela¬ 
tionships.  The  set  of  collected  attributes 
form  a  vocabularly  of  terms  that  can  be  used 
to  describe  software  components  by  their 
reusability-related  attributes. 

The  main  features  of  the  proposed 
classification  scheme  are  expandability,  adap¬ 
tability,  and  consistency.  Expandability 
means  that  new  classes  can  be  added  with  a 
minimum  of  reclassification  problems,  adap¬ 
tability  means  that  the  scheme  can  be  cus¬ 
tomized  to  a  particular  environment,  and 
consistency  means  that  components  from 
different  collections  in  the  same  class  share 
the  same  attributes. 


•Part  of  this  work  was  conducted  at  the  University 
of  California  Irvine  in  connection  with  the  author's  PhD 
dissertation 


This  paper  also  reports  current  work  on 
a  software-supported  query  system  that  facili¬ 
tates  retrievals  based  on  the  classification 
scheme  described. 

Library  Classification  Schemes 

Classification  is  the  act  of  grouping  like 
things  together.  All  members  of  a  group-  or 
class-  produced  by  classification  share  at  least 
one  characteristic  which  members  of  other 
classes  do  not  possess.  Classification  displays 
the  relationships  between  things,  and 
between  classes  of  things  and  the  result  is  a 
network  or  structure  of  relationships  which 
may  be  used  for  many  purposes. 

Classification  is  a  fundamental  tool  for 
the  organization  of  knowledge  and  pervades 
everyday  life  from  supermarkets  to 
warehouses  to  schools.  A  library  is  usually 
considered  as  the  typical  example  for 
classification  where  a  collection  has  been 
organized  for  easy  access  and  retrieval.  A 
collection  owes  its  organization  to  a 
classification  scheme  which  in  turn  is  based 
on  a  controlled  and  structured  index  vocabu¬ 
lary  called  the  classification  schedule.  The 
latter  consists  of  the  set  of  names  or  symbols 
representing  concepts  or  classes  and  is  listed 
in  a  systematic  order  to  display  the  relation¬ 
ships  between  classes. 

Classification  schemes  can  be  arranged 
in  two  ways:  enumerative  and  faceted.  The 
enumerative  or  traditional  method  is  to  pos¬ 
tulate  a  universe  of  knowledge  and  to  divide 
it  into  successive  narrower  classes  which  will 
include  all  the  possible  compounded  classes 
and  arrange  them  to  display  their  heirarchical 
relationships.  Dewey  Decimal  classification  is 
a  typical  example  of  an  enumerative 


decachotomy  based  hierarchy.  All  possible  specific  classes,  large  groups  of  very  similar 
classes  are  predefined.  components. 


The  faceted  method  relies  not  on  the 
breakdown  of  a  universe,  but  on  building  up 
or  ’synthesizing’  from  the  subject  statements 
of  particular  documents.  By  this  method, 
subject  statements  are  analyzed  into  their 
component  elemental  classes,  and  it  is  these 
classes  only  which  are  listed  in  the  schedule; 
and  their  generic  relationships  are  the  only 
relationships  displayed  on  its  pages.  When 
the  classifier  using  such  a  scheme  has  to 
express  a  compound  class,  he  does  so  by 
assembling  its  elemental  classes.  This  pro¬ 
cess  is  called  synthesis  and  the  arranged 
groups  of  elemental  classes  that  make  the 
scheme  are  the  facets.  Facets  are  sometimes 
considered  as  perspectives,  viewpoints  or 
dimensions  of  a  particular  domain. 

Systematic  order  in  a  faceted  scheme 
consists  in  ranking  the  facets  by  citation 
order  according  to  their  relevance  to  users  of 
the  collection.  Terms  within  facets  are 
ordered  by  their  relationship  to  each  other  or 
their  conceptual  closeness.  There  are 
different  user  selected  criteria  for  ordering 
terms  and  by  convention,  this  ordering  con¬ 
sists  of  a  one  dimensional  list  where  concep¬ 
tual  closeness  between  any  two  terms  is 
’measured’  by  the  number  of  terms  listed 
between  them.  When  classifying  in  a  faceted 
scheme,  the  most  significant  term  in  the 
classification  description  is  a  term  selected 
from  the  facet  that  is  most  relevant  to  the 
user. 

Software  Classification 

Faceted  schemes  are  very  attractive  for 
classifying  reusable  software  because  they 
are,  in  general,  more  flexible,  precise  and 
better  suited  classification  scheme  for  reus¬ 
able  software  components  has  been  proposed 
by  one  of  the  authors  (Prie85).  The  scheme 
proposes  a  component  description  format 
based  on  a  standard  vocabulary  of  terms, 
imposes  a  citation  order  for  the  facets,  and 
provides  a  conceptual  metric  to  measure  con¬ 
ceptual  distances  between  terms  in  each  facet 
for  a  more  effective  selection  of  closely 
related  items.  The  scheme  is  based  on  the 
criteria  that  collections  of  reusable  com¬ 
ponents  are  very  large  and  continuously 
growing,  and  that  they  are,  even  in  very 


An  experimental  collection  of  over  200 
program  descriptors  of  modules  ranging  from 
50  to  200  source  tines  of  code  was  used  to 
derive  facets  and  terms  of  a  preliminary 
software  schedule.  Two  groups  of  facets 
were  identified:  those  describing  functionality 
and  those  describing  the  environment,  three 
in  each  group.  It  was  observed  that  program 
descriptions  consist  of  two  parts:  one  describ¬ 
ing  the  functionality  (i.e.,  what  it  does)  and 
the  other  describing  the  environment  (i.e., 
where  it  does  it).  Implementation  details  or 
realization  (i.e.,  how  it  does  it)  were  not  usu¬ 
ally  included  in  a  description.  So,  function 
and  environment  were  selected  as  facets  and 
realization  characteristics  used  as  discriminat¬ 
ing  factors  to  separate  similar  components. 

It  was  observed  that  functionality 
equivalent  components  performed  essentially 
the  same  function  and  that  differences  in 
their  realizations  could  be  identified  indirectly 
through  some  intrinsic  characteristics  like 
size,  complexity,  and  programming  language 
used.  Implementation  differences  based  on 
intrinsic  factors  are  approximate  and  valid 
only  when  the  number  of  functionally 
equivalent  components  is  large. 

Functionality  -  The  three  facets  for  func¬ 
tionality  were  identified  by  observing  the 
imperative  nature  of  statements  describing 
functions,  e.g., 

<  input,  character,  buffer>, 

<substitute,  tabs,  file>, 

<  search,  root,  B-tree> 

Description  of  functionality  therefore  consist 
of 

<  function,  objects,  medium  > 

where  function  is  a  term  naming  the  func¬ 
tion,  objects  identifies  the  objects  manipu¬ 
lated  by  the  function  and  medium  identifies 
the  'locus’  of  the  action,  usually  a  data  struc¬ 
ture. 

Environment  -  The  facets  for  environment 
were  identified  as: 

<  system-type,  functional-area,  setting> 

where  system-type  is  an  application  indepen¬ 
dent  name  typically  given  to  the  basic 
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function  described  in  functionality.  For 
example,  report-formatter,  scheduler,  retri¬ 
ever,  expression-evaluator,  etc.  Functional- 
area  describes  a  particular  identifiable  applica¬ 
tion  dependent  function.  It  is  usually  defined 
by  an  established  set  of  procedures  in  an  area 
of  application  like  general-ledger,  cost- 
control,  operating-system,  etc.  Setting 
describes  the  location  where  the  application  is 
exercised.  It  captures  details  of  how  to  con¬ 
duct  certain  operations.  These  environment 
facets,  reflect  to  some  extent,  the  nature  of 
the  experimental  sample  used  but  collections 
in  other  domains  could  turn  up  with  other 
facets  such  as  type  of  security,  accessibility, 
or  design  methodology  used.  A  descriptor 
(i.e.,  classification  code,  call  name)  for  a  pro¬ 
gram  consists  in  defining  a  term  from  each 
facet  as  in: 

<  substitute/  backspaces/ file/  text_formatter/ 
program_development/software_shop> 

Conceptual  Closeness  -  An  important  feature 
of  this  scheme  is  the  introduction  of  a  con¬ 
ceptual  graph  to  measure  closeness  among 
terms  in  a  facet.  A  conceptual  graph  is  an 
acyclic  directed  graph  that  relates  every  term 
in  a  facet  through  a  set  of  weighted  edges. 
Terms  are  at  the  leves  and  the  nodes  are 
’super  types’  that  denote  general  concepts. 
Weights  are  user-assigned;  that  is,  the  closer 
the  user  perceives  a  relationship  of  a  term  to 
a  supertype,  the  smaller  the  weight.  The 
example  in  figure  1  shows  a  partial  weighted 
conceptual  graph  for  some  function  names. 
The  notions  or  supertypes  are  all  related  to 
the  notion  of  function  (*)  which  is  the  facet 
name.  Closeness  is  then  measured  by  the 
closest  path  between  any  two  terms;  for 
example,  measure  is  closer  to  add  (i.e.,  6) 
than  to  move  (i.e.,  16).  A  reuser  perspective 
was  used  for  weight  assignment  in  this  partic¬ 
ular  graph. 

One  practical  application  of  a  closeness 
measurement  happens  during  retrieval.  If  a 
particular  term  in  a  query  does  not  match  any 
available  descriptions  in  the  collection,  the 
system  then  tries  the  next  most  closely 
related  term  to  retrieve  descriptions  of 
closely  related  items. 

An  abstract  view  of  the  scheme  is 
presented  in  figure  2.  Each  component  (a) 


has  a  descriptor  (d  )  which  is  an  ordered  set 
of  terms  from  each  facet  (F  ).  Every  term 
in  a  facet  is  related  to  one  or  more  super¬ 
types  by  means  of  a  weighted  conceptual 
graph.  During  retrieval,  a  query  is  a  valid 
descriptor  d  of  terms  selected  from  each 
facet.  If  there  is  no  match  in  the  collection 
for  d  then  closely  related  terms  are  selected 
by  computing  distances  in  the  corresponding 
conceptual  graph  to  make  new  descriptors  d 
2<  i  <  n.  Matches  on  subsequent  d  ‘s  will 
retrieve  components  closely  related  to  com¬ 
ponents  described  by  d. 

It  is  assumed  that  components  require 
some  modifications  before  being  used  in  a 
new  application  based  on  the  fact  that  code  is 
very  specific  and  an  exact  match  between 
requirements  and  available  features  is  almost 
impossible.  Code  is  the  distilled  product  of 
several  design  decisions  for  which  there  is 
usually  no  documentation  unless  the  whole 
refinement  process  from  specification  through 
design  through  code  was  captured.  Even  in 
these  ideal  circumstances,  the  refinement 
process  is  so  long  and  involved  that  its  mere 
analysis  and  understanding  would  overcome 
any  reuse  effort.  Understanding  of  com¬ 
ponent  characteristics  through  indirect  means 
is  therefore  essential. 

Current  Work 

The  faceted  classification  scheme,  the 
conceptual  distance  model  and  a  mechanism 
to  evaluate  and  rank  functionally  equivalent 
components  were  integrated  into  a  prototype 
library  system.  An  SADT  level  0  diagram  of 
the  library  system  for  reusable  code  frag¬ 
ments  is  shown  in  figure  3. 

This  library  system  can  be  seen  as  a 
group  of  procedures  that  help  in  query  con¬ 
struction  and  in  the  evaluation  of  the 
retrieved  sample  for  potential  reusability. 
The  data  base  of  component  descriptors  is 
considered  to  be  the  catalog. 

The  query  system  (boxes  1.2.  and  3) 
makes  use  of  the  classification  scheme  to 
interactively  generate  component  descriptors 
(groups  of  valid  terms  used  to  describe  a 
component).  The  system  guides  the  user  in 
selecting  valid  terms  from  the  classification 
schedules  and  enforces  a  citration  order  for 
the  terms  based  on  the  established  relevance 
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order  of  the  six  previously  defined  facets.  A 
query  is  a  six-tuple  descriptor  of  a  com¬ 
ponent.  A  query  may  be  modified  by  inser¬ 
tion  or  removal  of  terms  in  a  prescribed 
order  (from  less  to  more  relevant)  resulting 
in  a  specialization  or  generalization  of  the 
query. 

A  query  may  also  be  expanded. 
Queries  of  closely  related  terms  are  con¬ 
structed  based  on  their  conceptual  distance. 
Conceptually  closer  terms  are  selected  first 
for  the  new  queries.  Groups  of  queries  are 
ordered  by  their  relevance  to  the  original 
query.  The  result  is  an  ordered  set  of  queries 
from  most  to  least  ’related’  to  the  original 
query.  Scope  of  expansion  is  controlled  by 
the  user.  Expansion  is  used  when  the  origi¬ 
nal  query  returns  the  empty  set.  Query 
expansion  is  central  to  the  library  system. 

Retrieval  (box  4)  is  implemented  by  a 
relational  data  base  system  where  each  pro¬ 
gram  descriptor  is  a  tuple  in  the  database 
with  pointers  to  source  code,  documentation 
and  other  relevant  information.  Evaluation 
(box  5)  is  a  system  of  its  own  that  normal¬ 
izes  reusability  related  metrics  and  ranks  the 
sainpie  according  to  the  estimated  reusability 
effort  required  to  reuse  the  components. 

The  evaluation  system  is  based  on  the 
assumptions  that  the  collection  of  com¬ 
ponents  is  very  large;  that  several  com¬ 
ponents  in  a  given  class  of  components  in  the 
collection  may  be  functionally  equivalent; 
and  that  there  is  a  need  to  assist  the  user  in 
selecting,  from  among  all  functionally 
equivalent  components,  the  one  easiest  to 
reuse.  The  evaluation  mechanism  estimates 
potential  reusability  effort  based  on  four  basic 


software  metrics  and  on  reuser  experience. 
Reuser  experience  is  used  as  a  modifier  for 
the  other  metrics  to  adjust  their  relevance. 

Tests  with  the  library  system  showed 
better  retrieval  performance  in  terms  of  user 
satisfaction  than  regular  relational  data  base 
systems.  Because  of  the  relatively  small  size 
of  the  collection  and  the  limited  number  of 
participants,  the  results,  although  very 
encouraging,  are  only  indicative  at  this  time 
rather  than  conclusive  but  work  is  on  the  way 
to  scale  up  the  collection  and  test  the  system 
in  a  production  environment. 

Effort  is  under  way  to  implement  these 
concepts  of  software  classification  and  reusa¬ 
bility  in  the  domain  of  information  manage¬ 
ment  software  at  GTE.  Reusable  assets  has 
been  the  focus  and  a  preliminary  analysis  of 
the  assets  domain  has  resulted  in  the 
definition  of  four  basic  facets;  asset-type 
(e.g.,  software,  hardware,  information), 
application-area  (e.g.  business,  telecommuni¬ 
cations,  systems),  complexity-level  (e.g. 
code- fragments,  subcomponents,  modules, 
subsystems),  and  reuse-mode  (e.g.  modify, 
adapt,  use-as-is.  call,  insert).  Work  is  under 
way  to  expand  facets  and  populate  the 
schedules  with  appropriate  terms  for  each 
facet.  Terms  will  be  defined  from  the 
analysis  of  a  representative  sample  of  assets 
and  asset  descriptions.  A  library  system  for 
asset  management  will  be  the  logical  follow 
up  in  this  project. 

[PRIE851  Prieto-Diaz.  R.  A  Software 
Classification  Scheme,  Ph.D  dissertation. 
Department  of  Information  and  Computer 
Science,  University  of  California,  Irvine, 
1985 


Figure  3.  SADT  Level  0  Acligram  for  a  Library  System 
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CLASSIFICATION  SCHEME: 


1-  Definitions 

2-  Classification  Schemes 

3-  Faceted  Schemes 

4-  Our  Scheme 
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DEFINITIONS 

ClassiRcation:  Discovery  and  display  of  concepts  and 

their  relationships. 
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Example: 

Eagle  —  bird  of  prey,  day  hunter 

Owl  —  bird  of  prey,  night  hunter 

ClassiRcation  Scheme:  Tool  for  arranging  concepts  and 

relationships  in  a  systematic 
order  based  in  a  controlled 
index  vocabulary. 

Index  Vocabulary:  Ordered  set  of  names  which 

represent  concepts. 

Examples: 

vertebrates- amphibians-frogs- toads 


000  Generalities 

100  Philosophy  and  related  disciplines 

200  Religion 

300  The  social  sciences 

400  Language 

500  Pure  sciences 

600  Technology  (applied  sciences) 

700  The  arts 

800  Literature 

900  Geography  and  history 


Relationships: 

Hierarchical  — *■  Indicate  subordination  or  inclusion, 
(animal-vertebrate-birds-eagle-golden  eagle) 

Syntactical  — *  Between  terms  in  classes  defined  by 
one  or  more  characteristics. 

migratory  birds 
birds  of  the  sea  shore 
the  respiration  of  birds 


Classification  Schemes: 

Faceted  — Based  on  synthesis 
Enumerative  —*■  Based  on  exhaustive  listings 


Facet  — ►  A  perspective 


EXAMPLES 


Domain  — ►  animals/ fauna 

Facets  — >  by  effect  on  man 
by  habit 
by  habitat 

by  land  form 
by  ground  cover 
by  latitude 
by  element 

by  zoologist  taxonomy 


A  Faceted  Scheme: 

(process  facet) 

Physiology 

Respiration 

Reproduction 

(animals  facet) 

(by  habitat  subfacet) 

Water  animals 
Land  animals 

(by  zoologists’  taxonomy  subfacet) 
Invertebrates 
Insects 
Vertebrates 
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An  Enumerative  Scheme: 

Physiology 

Respiration 

Reproduction 


Water  animals 
Physiology  of  water  animals 
Respiration  of  water  animals 
Reproduction  of  water  animals 
Land  animals 
Physiology  of  land  animals 
Respiration  of  land  animals 
Reproduction  of  land  animals 
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Invertebrates 

Physiology  of  invertebrates 
Respiration  of  invertebrates 
Reproduction  of  invertebrates 
Water  invertebrates 
Physiology  of  water  invertebrates 
Respiration  of  water  invertebrates 
Reproduction  of  water  invertebrates 
Land  invertebrates 
Physiology  of  land  invertebrates 
Respiration  of  land  invertebrates 
Reproduction  of  land  invertebrates 


Insects 

Physiology  of  insects 
Respiration  of  insects 
Reproduction  of  insects 
Water  insects 

etc.... 
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FACETED  vs.  ENUMERATIVE  SCHEMES 


•  ENUMERATIVE 

+  Extensive 
+  Usually  incomplete 
4-  Rigid 

+  Central  hierarchy 


•  FACETED 

+  Brief 

+  High  resolution 
+  Amenable  to  automation 
+  Flexible 


FACETED  SCHEMES 


•  Facet  Ordering 


Animal  Facets  Relevance 

Respective  more  — .  — - —  ■  —  -  ^  less 


Zoologist 

taxonomy  habitat  habit 

effect  on  man 

Marine  Biologist 

habitat 

taxonomy  habit 

effect  on  man 

Environmentalist 

effect  on 

man  habit  habitat 

taxonomy 

•  Term  ordering  — ► 

Display  relationship  by 
lin/ear  ordering 

mercury 

solitary  animals 

venus 

herd  animals 

earth 

social  animals 

mars 

etc.. 

etc.. 

•  Synthetic  Classification 

title  classification 

a)  Salt  water  fish - >  fish/marine 

b)  Frogs  of  the  lake - >  frogs/lake 

c)  Butterflies  of  the  river  —  >  butterflies/river 


OUR  SCHEME  — ►  Faceted 


-  Precision  on  software  component  descriptions 

-  Expandable 

-  Flexible 

-  Provides  metric  for  closeness  of  relationships 


Metrics: 


Facet  level  — ►  Relevance  between  facets 

(facets  ordered  from  most  to  less  relevant) 


Term  level  —►  Use  of  user  defined  supertypes 
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ABSTRACT  VIEW  OF  THE  SCHEME 


THE  COMPONENT 


/ 
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THE  CONCEPTUAL 
DISTANCE  GRAPH 


IMPLEMENTATION: 


1-  Observations 

2-  Facet  Selection 

3-  Synonym  Control 

4-  Component  Evaluation 
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OBSERVATIONS: 


•  Component  Descriptions  — ♦  Syntactical  relationships 

among  terms 


add  file  to  archive 

read  lines  from  a  file 

convert  string  to  floating  number 


Tension  Problem  on  description  detail 


High- 


Low 


Precision  in 
descriptor 


Probability  of 
a  match 


Low 


High 


number  of  facets 


PARTIAL  SCHEDULE: 


FUNCTIONALITY 

(citation  order  — ►  — ► 


input 

output 

move 

append 

insert 

extract 

substitute 


delete 
compare 
par 
dec 


{objects} 

{  medium 

tabs 

keyboard 

backspaces 

mouse 

digits 

sensor 

characters 

printer 

patterns 

display 

tokens 

cards 

integers 

tape 

reals 

wnrHq 

r 

disk 

ff  vl  VIS 

strings 

SpccUl 

file 

lines 

table 

measure 
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SYNONYM  CONTROL 


Why?  People  have  different  interpretation  for 
different  terms. 


<move,  words>< 

<  transfer,  names  > 


same  concept 


Need  to  unify  descriptors  under  same  concept 


SOME  FUNCTION  SYNONYMS 


GIVEN  NAME 

SYNONYMS 

input 

data_entry/scan /enter /read  / 

output 

data_output/ print/echo/show  /  write/ display  / 

move 

transfer/copy/ 

append 

affix/attach  /  concatenate/join  / 

insert 

include/push/ 

extract 

pick/ 

substitute 

replace/exchange/transliterate/ 

delete 

remove/erase/cancel  / 

compare 

test/ 

parse 

recognize/ 

decode 

multi-way  /  muti_branch  /  selector/ 

search 

look_up/find/ 

measure 

count/advance/size/ 

split 

separate/break_u  p  / 

COMPONENT  EVALUATION 

m 

•  Attribute  Selection  Criteria 

-  Validated  metrics 

-  Objective 

-  Easy  to  use 

-  Related  to  program  understanding 

•  Selected  attributes 

-  Program  size  — ►  Source  lines  of  code 

-  Program  complexity  — »  Conditional  statements 

-  Programming  languge  — *  Similarities  between 

source  and  target 
languages 

-  Documentation  — ►  Quality  score 


METRIC  NORMALIZATION 


Why?  Ability  to  rate  and  rank  similar  components 

Problem:  Attribute  metrics  function  of  other  factors 

Introduction  of  memebrship  functions 
from  fuzzy  set  theory 


EXAMPLE 

Attribute:  Component  Size 

Measure  degree  of  membership  to 
the  class  of  small  components 


FORTRAN 


Assembly 


Role  of  Reuser  experience: 


Lines  of  Code 


modifier  of  membership  functions 


Small  Component 


from  a  neutral  perspective 

—  for  a  novice  programmer 

/ — for  an  expert  programmer 


lines  of  source  code 
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SUMMARY  OF  CONTRIBUTIONS 


•  An  expandable  and  adaptable  scheme 
for  software  classification. 

•  An  approach  to  measure  closeness 
among  terms  in  faceted  schemes. 

•  A  process  to  define  facets  and 
introduction  of  six  reuse  related  facets. 


•  Introduction  of  six  reuse  related 
attributes  and  their  metrics. 

•  Ability  to  normalize  reuse  related 
metrics  by  using  fuzzy  functions. 

•  These  concepts  can  be  integrated  into 
a  library  system  as  demonstrated  by 
prototype. 


GUIDELINES  FOR  WRITING  REUSABLE 
ADA  (R)  SOFTWARE 


Rick  St.  Dennis 

Honeywell  Inc. 
Computer  Sciences  Center 
1000  Boone  Avenue  North 
Golden  Valley,  Minnesota  55427 

ABSTRACT 


Software  reuse  is  key  to  significant  gains  in  programmer  productivity.  However,  to  achieve  its 
full  potential  guidelines  for  writing  reusable  software  must  exist  and  be  followed.  While  language 
independent,  measurable  characteristics  of  reusable  software  can  be  the  basis  for  these  guidelines,  the 
guidelines  themselves  should  be  language-specific.  This  paper  describes  ongoing  research  at  the 
Honeywell  Computer  Sciences  Center  to  define  a  set  of  characteristics  of  reusable  software  as  well  as 
guidelines  for  implementing  them  in  the  Ada  language. 

Keywords:  Ada,  reusable  software  parts,  reusability,  object-oriented  programming. 
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1.  Introduction 

Both  software  production  costs  and  the 
amount  of  new  software  produced  annually 
are  skyrocketing.  In  1980,  the  U.S  Depart¬ 
ment  of  Defense  (DoD)  spent  over  $3  billion 
on  software.  By  1990,  their  expenses  are 
expected  to  grow  to  $30  billion/year 
[HOROWITZ84],  If  current  development 
trends  continue,  future  costs  will  be 
increased  even  more  by  unreliable  software, 
software  delivered  late,  and  continuing 
maintenance  problems. 

Today’s  software  needs  outpace  our 
ability  to  produce  it,  as  shown  by  the  back¬ 
logs  in  MIS  departments  nationwide,  and 
needs  are  growing  each  year  [STARS83], 
There  is  and  will  continue  to  be  a  serious 
shortage  of  qualified  programmers  to  meet 
these  needs.  One  might  expect  productivity 
increases  for  programmers  to  make  up  for  at 
least  a  part  of  this  shortage.  However, 
software  development  has  been  relatively 


small  year-to-year  productivity  increases  as 
contrasted  with  dramatic  increases  in 
hardware  fabrication  [HOROWITZ84).  We 
feei  that  a  key  to  significant  gains  in  program¬ 
mer  productivity  lies  in  the  area  of  software 
is  an  exponential  function  of  its  size.  Halv¬ 
ing  the  amount  of  new  software  built  will 
more  than  halve  the  cost  of  building  the 
software  that  we  need  [JONES84], 

Software  reuse  is  an  important  part  of 
the  RAPIER  (Rapid  Prototyping  to  Identify 
End-User  Requirements)  project  for  many  of 
the  same  reasons  it  is  important  tc  software 
productivity  increases  in  general.  One  of 
RAPIER’s  main  goals  is  "...to  develop  a  pro¬ 
totype  engineering  environment  [that  will 
provide  tools  and  techniques  for  developing 
modifiable  prototypes  q-ickly  and  inexpen¬ 
sively..."  [RAPIER86'  The  approach  to 
achieving  this  goal  is  to  build  prototypes  from 
n  usable  software  parts.  It  is  the  characteris¬ 
tics  of  these  reusable  software  parts  that  will 
provide  the  modifiability,  and  the  rapid  and 


inexpensive  development  of  prototypes  that 
RAPIER  requires. 

To  date,  no  adequate  characterization  of 
what  makes  software  reusable  exists.  It  is 
quite  common  to  read  unmeasurable,  qualita¬ 
tive  admonitions  as  to  what  makes  software 
reusable  and/or  specific  examples  of  software 
that  is  claimed  to  be  reusable.  However, 
these  admonitions  (or  "metacharacteristics") 
and  software  exampies  are  not  enough. 
Measurable  characteristics  of  reusable 
software  are  needed  as  well  as  specific  guide¬ 
lines  to  implement  them  in  source  code. 
Only  through  use  of  these  characteristics  and 
guidelines  can  the  full  potential  of  reusability 
be  achieved. 

The  RAPIER  project  has  developed 
Version  1.0  of  "A  Guidebook  For  Writing 
Reusable  Source  Code  in  Ada  (R)" 
[STDENNIS86],  [RAPIER86],  This  guide¬ 
book  contains  three  reusability  metacharac¬ 
teristics,  fifteen  measurable  characteristics 
that  realize  the  metacharacteristics,  and  63 
guidelines  for  implementing  these  charac¬ 
teristics  in  Ada  source  code.  Guidebook 
chapters  are  organized  to  follow  the  Ada 
Language  Reference  Manua:  (DOD83].  Ver¬ 
sion  1.0  of  the  guidebook  contains  selected 
chapters  covering  all  major  Ada  program 
units,  program  structures,  compilation  issues, 
and  visibility  rules.  Example  Ada  modules 
that  were  written  following  the  guidelines  are 
also  provided.  This  guidebook  provides  the 
RAPIER  project  with  a  basis  to  begin  writing 
reusable  Ada  software  parts  to  be  used  in  its 
prototyping  system. 

This  paper  outlines  the  approach  to 
achieving  reusability  we  prescribe  in  our 
guidebook.  In  it  we  list  our  reusability 
characteristics,  highlight  one  characteristic, 
and  provide  guidelines  supporting  it.  We  also 
provide  example  Ada  modules  written  follow¬ 
ing  the  guidelines,  discuss  the  relationship 
between  our  reusability  guidebook  and  the 
STARS  Application  Area,  and  outline  plans 
for  future  work. 

2.  Our  Approach  To  Achieving  Reusability 

Our  approach  to  reusing  source  code 
centers  around  reusable  components,  written 
as  Ada  packages,  classified  for  both  browsing 
and  retrieval,  and  residing  in  a  library  or 


software  base.  See  Section  5  of  [RAPIER86]. 
We  believe  that  the  features  of  the  Ada 
language  combined  with  a  set  of  software 
design  and  coding  guidelines  supporting 
characteristics  of  reusable  software  wiil 
enable  creation  and  reuse  of  software  in  a 
manner  not  possible  with  most  other 
languages  and  systems.  These  guidelines  will 
constrain  how  Ada  software  is  written  for  the 
sake  of  reusability. 

Companion  work  at  Honeywell’s  Com¬ 
puter  Sciences  Center  is  also  addressing  the 
organization  and  composition  principles  that 
will  provide  a  framework  for  reuse  of  com¬ 
ponents.  A  classification  of  components 
according  to  behavior  has  been  proposed  in 
Section  5  of  [RAPIER86].  Program  composi¬ 
tion  using  an  adaptation  of  the  operational 
paradigm  for  program  design  has  also  been 
proposed  in  Section  3  of  [RAPIER86].  A 
high-level  language  for  composing  programs 
of  components  drawn  from  a  software  base 
using  a  Prototype  System  Description 
Language  (PSDL)  is  being  designed  by  Inter¬ 
national  Software  Systems,  Inc.  (ISSI) 
[ISSI86],  So  the  characteristics  and  guidelines 
in  our  guidebook  fit  into  an  overall  approach 
to  reusability. 

3.  Reusability  Metacharacteristics 

We  propose  these  metacharacteristics  of 
reusable  software: 

(I)  Candidate  software  for  reuse  must  be 
able  to  be  found. 

Findable  software  must  comprise  both 
code  and  specification.  At  a  minimum, 
the  specification  tells  users  what  a 
software  part  does,  thus  allowing  them 
to  decide  whether  it  meets  their  func¬ 
tional  needs.  A  specification  may 
describe  attributes  of  the  software  part 
such  as  author,  hardware  dependencies, 
execution  time  on  a  particular 
configuration,  and  so  forth  which 
further  assist  users  in  deciding  what 
software  is  appropriate. 

The  apparatus  for  storing  and  managing 
software  contributes  greatly  to  its  finda- 
bility.  That  apparatus  includes  a 
software  base  management  system  and 
intelligent  schemes  for  classifying 
software  so  that  searches  into  the 


software  base  are  successful  without 
being  frustratingly  long. 

It  must  be  significantly  less  costly  to 
find  software  and  reuse  it  than  to 
recreate  it.  Both  the  specifications  and 
the  apparatus  for  managing  the  reusable 
software  must  support  relatively  low 
(human  and  machine)  overhead  for 
storing  software  and  searching  for  it. 

(2)  Once  found,  software  must  be  under¬ 
stood  enough  to  be  reused. 

This  requirement  involves  both  the 
software  part’s  specification  and,  if  its 
code  is  to  be  modified,  the  way  in 
which  it  is  coded.  There  are  judgments 
to  be  made  about  what  attributes  of  a 
software  part  reusers  need  to  know  in 
order  to  decide  whether  the  software 
meets  their  needs. 

If  the  software  is  to  be  modified,  it 
must  be  engineered  so  that  reusers  can 
examine  the  code  and  make  changes 
that  do  introduce  errors  or  unwanted 
side  effects,  and  that  do  make  the 
desired  alterations. 

(3)  Once  found  and  understood,  it  must  be 
feasible  to  reuse  the  software. 

Software  that  can  be  reused- 

o  is  built  for  reuse  -  constructed  under  the 
constraint  that  it  will  be  reused. 

o  is  fit  for  reuse  (i.e.,  is  a  "plug-  compatible" 
part)-composable  with  other  code  in  such  a 
way  that  it  neither  interferes  with  that  other 
code  nor  allows  itself  to  be  interfered  with. 

o  displays  conceptual  clarity  or  appropriate¬ 
ness  -  presents  a  useful  abstraction  (such  as  a 
table,  a  database,  a  sensor  or  a  stack)  at  an 
"appropriate"  level. 

Each  of  the  software  characteristics 
listed  in  Section  4  is  a  means  of  achieving 
one  (or  some)  of  these  metacharacteristics. 
Figure  1  below  relates  each  of  the  proposed 
characteristics  to  the  metacharacteristics  it 
promotes. 

4.  Reusability  Characteristics 

4.1  Criteria  For  Reusability  Characteristics 

The  reusability  metacharacteristics  in 
Section  3  are  qualitative  “good  practice" 


admonitions.  In  general,  the  characteristics 
listed  in  this  section  are  measurable  or  judg- 
able  qualities  that  software  should  possess  in 
order  to  meet  the  metacharacteristics.  We 
have  proposed  characteristics  that  are  statisti¬ 
cally  measurable  or  judgable  today  or  will  be 
measurable/judgable  once  we  have  more 
experience  with  reusable  software.  For 
example,  today  we  can  measure  if  software  is 
free  from  hidden  side  effects.  However,  we 
cannot  judge  whether  software  has  the  right 
balance  between  generality  and  specificity. 
Only  when  software  has  been  reused  for 
some  time,  we  will  be  able  to  judge  this  qual¬ 
ity. 

The  characteristics  listed  below  are  also 
reuse-specific;  using  them  will  produce 
software  that  is  designed  and  coded  a  priori 
for  reuse.  "Good"  software  engineering  prac¬ 
tices  will  contribute  to  reuse  but  will  not 
specifically  make  software  reusable. 

Our  guidebook  only  briefly  discusses  an 
important  aspect  of  reusability  domain  or 
application  specificity.  We  expect  that  appli¬ 
cation  specificity  will  be  a  major  factor  in 
enabling  software  reuse  [FRANKOW- 
SKI85B],  However,  just  as  all  software 
intended  for  reuse  must  be  built  using  good 
software  engineering  practices,  it  must  be 
built  using  application  neutral  basic  reusabil¬ 
ity  guidelines  in  addition  to  application 
specific  guidelines.  The  characteristics  listed 
below  are  those  underlying  guidelines  for 
reusability  across  application  areas. 

In  our  guidebook,  we  post  15 
language-independent  characteristics  of  reus¬ 
able  software.  For  the  purposes  of  this 
paper,  we  list  all  characteristics  and  highlight 
#4:  Component  is  designed  as  object- 
oriented;  that  is,  packaged  as  typed  data  with 
procedures  and  functions  which  act  on  that 
data. 

4.2  List  of  Characteristics 

(1)  Interface  is  both  syntactically  and 

semantically  clear  [STANDISH84] 

(2)  Interface  is  written  at  appropriate 

(abstract)  level. 

(3)  Component  does  not  interfere  with  its 

environment;. 


(4)  Component  is  designed  as  object- 
oriented;  that  is,  packaged  as  typed  data 
with  procedures  and  functions  which  act 
on  that  data. 

An  object  orientation  to  code  involves 
mapping  of  "solutions"  to  our  human 
view  of  the  "problems”  the  software  is 
trying  to  solve  [BOOOCH833.  Our 
human  view  involves  objects,  attributes 
of  these  objects,  and  operations  on 
objects  expressed  in  a  noun/verb  sense 
in  English.  An  object-orientation  to 
software  aids  understandability  since 
solutions  to  problems  are  expressed  in 
our  "human  terms. 

Reusable  software  should  act  on  objects 
explicitly.  What  we  are  advocating  here 
is  a  clear  definition  and  method  of  "act¬ 
ing"  on  objects.  All  actions  or  opera¬ 
tions  on  objects  should  be  defined  as 
subprograms  (or  their  equivalent)  with 
the  objects  as  parameters.  Further¬ 
more,  the  objects  or  at  least  their  types 
should  be  "packaged”  as  close  to  the 
definition  of  the  operations  on  them  as 
possible.  Ideally,  they  should  be  pack¬ 
aged  together  to  ease  location,  refer¬ 
ence,  and  use.  To  promote  reusability 
it  is  better  not  to  use  global  data  that  is 
changed  implicitly  by  routines  to  which 
it  is  visible  but  to  pass  the  data  to  rou¬ 
tines  as  parameters  making  it  explicit 
that  (1)  these  routines  are 
actors/operators  on  the  data  and  (2) 
that  is  just  how  this  data  will  be  treated 
(e.g.,  as  input  only,  as  a  constant,  and 
so  forth). 

Based  on  Section  5  of  [RAPIER86],  we 
will  define  operations  on  data  in  context 
as  implementations  of  behaviors  that 
characterize  objects,  the  objects  being 
defined  by  the  set  of  all  behaviors  asso¬ 
ciated  with  them. 

(5)  Actions  based  on  function  results  are 
made  at  the  next  level  up. 

(6)  Component  incorporates  scaffolding  for 
use  during  "building  phase". 

(7)  Separate  the  information  needed  to  use 
software  specification,  from  the  details 
of  its  implementation,  its  body. 


(8)  Component  exhibits  high  cohesion/low 
coupling  [BERGLAND81], 

(9)  Component  and  interface  are  written  to 
be  readable  by  persons  other  than  the 
author. 

(10)  Component  is  written  with  the  right 
balance  between  generality  and 
specificity  [MATSUMOT084], 

(11)  Component  is  accompanied  by  sufficient 
documentation  to  make  it  findable. 

(12)  Component  can  be  used  without  change 
or  with  only  minor  modifications. 

(13)  Insulate  a  component  from  host/target 
dependencies  and  assumptions  about  its 
environment;  isolate  a  component  from 
format  and  content  of  information 
passed  through  it  which  it  does  not  use. 

(14)  Component  is  standardized  in  the  areas 
of  invoking,  controlling,  terminating  its 
function  [FONES84],  error-handling, 
communication  and  structure 
[LANIERGAN84], 

(15)  Components  should  be  written  to 
exploit  domain  of  applicability  [NEIGH- 
BOR84];  components  should  constitute 
the  right  abstraction  and  modularity  for 
the  application. 

Figure  1  relates  each  of  the  proposed 
characteristics  to  the  metacharacteristics  it 
promotes. 

5.  Reusability  Guidelines 

In  this  section  we  provide  7  Ada- 
specific  guidelines  from  our  guidebook  that 
support  reusability  characteristic  number  4 
pertaining  to  object-oriented  software. 
[FRANKOWSKI86A]  also  discusses  use  of 
an  object-oriented  paradigm  to  build  reusable 
Ada  software. 

5.1  Context  For  Guidelines 

There  are,  in  general,  two  kinds  of 
reusable  software  parts  -  directly  reusable 
parts  and  indirectly  reusable  parts.  Directly 
reusable  parts  are  those  whose  behavior  or 
effect  is  catalogued,  that  is,  "advertised"  in 


the  catalog(l)  of  reusable  software  that 
developers  use  to  determine  what  software 
parts  are  available  for  reuse.  Directly  reus¬ 
able  parts  are  what  developers  search  for  and 
choose.  Indirectly  reusable  parts  support 
directly  reusable  parts;  they  provide  the 
environment,  the  ancillary  definitions  and 
data  that  the  directly  reusable  parts  need  in 
order  to  perform  correctly.  In  the  ideal  case, 
indirectly  reusable  parts  are  incorporated  into 
the  program  under  construction  automatically 
by  a  software  base  management  system. 

(1)  A  catalog  can  be  an  automated  software 
repository’s  classification  scheme,  a  list 
of  component  names  and  descriptions 
on  paper,  or  even  a  rumor  the 
developer  hears  from  a  colleague  down 
the  hall. 

Reusable  parts  should  be  objects.  As 
abstractions,  objects  have  properties  (data) 
and  allowable  operations  on  this  data.  The 
Ada  package  should  be  the  realization  or  con¬ 
crete  implementation  of  the  object  abstrac¬ 
tion.  Types  and  data  objects/  variables 
implement  data;  subprograms/ tasks  imple¬ 
ment  operations.  Packages  bundle  these 
things  up  nicely. 

5.2  Sample  Guidelines 

The  following  guidelines  taken  from 
our  guidebook  prescribe  how  to  write  reus¬ 
able  Ada  software  satisfying  an  object- 
oriented  paradigm.  Guidelines  G10-1,  G10- 
2,  and  G10-3  provide  a  specific  scheme  for 
writing  reusable  Ada  software  in  terms  of 
Ada  compilation  units.  Guidelines  G6-2, 
G6-3,  G7-2,  and  G9-2  support  this  scheme 
for  Ada  subprograms,  packages,  and  tasks. 
We  encourage  use  of  generic  subprograms 
and  packages  in  compliance  with  these  guide¬ 
lines.  Please  refer  to  our  guidebook  for 
further  details  on  the  use  of  generics. 

G10-1:  Use  library  unit  package  specifications 
as  the  encapsulation  mechanism  for  directly 
reusable  software  (i.e,  data  and  operations  on 
the  data). 

Library  unit  packages  are  our  "unit  of 
reusability"  with  packages  specifications  as  the 
standard  unit  for  directly  reusable  software 


parts.  It  is  the  specifications  of  operations  on 
data  as  well  as  data  contained  in  these  pack¬ 
ages  that  are  directly  reusable.  These  opera¬ 
tions  are  in  effect  interfaces  to  reusable 
objects.  See  Figure  2. 

G10-2:  Only  "first  level"  nested  nonpackage 
entities  in  library  unit  package  specifications 
form  the  basis  for  "catalogued"  directly  reus¬ 
able  objects/ software. 

Ada  packages  can  be  nested  to  any  level 
allowed  by  a  compiler  implementation,  and 
nesting  can  be  used  as  desired  for  imple¬ 
menting  reusable  components.  However,  for 
each  of  "cataloging"  there  should  be  a  practi¬ 
cal  limit  to  the  level  of  nesting  of  packages 
that  encapsulate  reusable  software.  G10-2 
simply  states  that  only  first-level  data  and 
specifications  for  operations  on  data  form  the 
basis  for  reusable  software  and  are  "catalo¬ 
gued".  Data  and  operations  within  nested 
packages  are  not  catalogued  as  reusable  even 
though  they  are  accessible  to  client  programs 
according  to  the  Ada  language  definition. 
Nesting  can  easily  complicate  the  environ¬ 
ment  or  context  for  reusable  software.  For 
example,  nesting  provides  an  environment 
for  declaration  order  information  hiding,  and 
visibility  rules  which  is  hard  to  reuse  and  to 
understand,  and  in  which  operations  and  data 
are  hard  to  classify.  Classifying  only  entities 
that  are  visable  at  the  first  level  as  reusable 
operations  on  data  in  context  w<ll  avoid  this 
complication. 

G10-3:  Use  secondary  unit  package  bodies, 
package  specifications  containing  only  data, 
and  subunits  corresponding  to  first-level 
package  body  nested  stubs  as  the  encapsula¬ 
tion  mechanism  for  indirectly  reusable 
software. 

This  guideline,  along  with  G10-1,  states 
that  all  reusable  Ada  software  should  be  writ¬ 
ten  in  terms  of  packages.  In  particular,  sub¬ 
programs  (with  the  exception  of  main  sub¬ 
programs)  and  tasks  should  be  written  either 
directly  within  the  declarative  parts  of  library 
unit  packages  or  in  that  context  through  the 
use  of  body  stubs.  In  Ada,  main  programs 
must  not  be  contained  in  packages.  How¬ 
ever,  we  do  not  treat  them  as  reusable.  It  is 
the  library  unit  packages  they  reference  that 
are  reusable.  Secondary  unit  (library  unit) 
package  bodies  are  indirectly  reusable. 


Subprograms  and  tasks  in  the  context  of 
secondary  unit  packages  (e.g.,  package 
bodies)  are  indirectly  reusable.  Library  unit 
package  specifications  containing  only  data 
are  indirectly  reusable  as  well.  See  Figure  2 
to  clarify  the  distinction  between  directly  and 
indirectly  reusable  software  parts. 

G6-2:  All  reusable  subprograms  except  a 
main  program  must  be  written  within  a 
library  unit  package. 

In  view  of  guidelines  G10-1  and  G10-3 
reusable  subprograms  must  be  written  in 
packages.  These  packages  and  their  contents 
are  the  reusable  software  in  a  software  re¬ 
pository;  they  are  "glued"  together  by  a  main 
program  which  is  invoked  from  the  environ¬ 
ment.  If  this  gluing  is  automatic  or  easily 
specifiable  in  a  very  high-level-language, 
main  programs  do  not  have  to  be  kept  in  a 
repository.  It  is  the  reusable  parts  that  they 
glue  together  that  are  important.  However,  if 
a  main  program  glues  together  a  "system" 
which  can  be  viewed  as  a  potential  com¬ 
ponent  of  other  systems,  then  that  program 
should  be  put  in  a  package  which  will  be 
catalogued  as  directly  reusable  software  and 
should  be  called  from  "another  main  pro¬ 
gram"  . 

G6-3:  Use  subprogram  declarations  to  specify 
interfaces  to  reusable  objects.  Use  subpro¬ 
gram  bodies  to  implement  these  interfaces 
and  properties  of  the  objects. 

The  interfaces  to  reusable  objects 
specified  in  subprogram  declarations  comprise 
a  name,  parameters  of  particular  types  and 
modes,  and  return  types  for  functions.  Sub¬ 
program  bodies  contain  the  executable  code 
fo.  reusable  objects.  This  code  performs  use¬ 
ful  work.  We  are  saying  that  the  use  of  both 
subprogram  declarations  and  bodies  is  impor¬ 
tant.  The  only  exception  to  this  guideline  is 
a  main  program  callable  from  the  environ¬ 
ment  rather  than  by  other  software.  In  this 
case,  a  body  alone  is  sufficient.  This  guide¬ 
line  is  related  to  G7-2  prescribing  that  pack¬ 
age  specifications  implement  interfaces  to 
object  abstractions  and  their  bodies  imple¬ 
ment  specific  details  of  these  abstractions. 

G7-2:  Use  package  specifications  to  specify 
the  interface  to  object  abstractions:  use  pack¬ 
age  bodies  to  encapsulate  implementation- 


specific  details  of  these  abstractions  not 
needed  by  client  software. 

Simply  stated,  decide  what  object 
abstraction  a  package  should  implement, 
decide  what  the  interface  to  this  abstraction 
should  be,  and  implement  these  as  visible 
specifications  for  operations  on  data  in  the 
public  part  of  a  package  specification.  Decide 
what  the  implementation  structure  of  the 
abstraction  should  be  and  implement  this  and 
all  other  details  in  the  private  part  of  the 
package  specification  and  a  corresponding 
package  body.  This  separation  benefits  the 
package  itself  and  its  environment.  The  less 
"connection"  a  package  has  with  the  outside 
world  (e.g.,  the  smaller  the  visible  part  of  a 
package  specification),  the  lower  its  coupling 
with  other  modules.  Once  modules  in  a 
package’s  environment  begin  to  depend  on 
particular  visible  entities  that  really  should 
have  been  hidden,  the  package  becomes  less 
and  less  insulated  from  its  environment. 

There  are  two  strategies  for  providing 
abstractions  as  reusable  objects  [BOOCH85]. 
These  are:  (1)  using  packages  to  implement 
abstract  data  types  and  (2)  using  packages  to 
implement  abstract  state  machines. 

(1)  Abstract  Data  Types:  Provide  the  basis 
for  multiple  "public"  reusable  objects 
with  common  operations  on  implemen¬ 
tations  of  the  operations  in  correspond¬ 
ing  package  bodies.  The  object  abstrac¬ 
tion  can  then  be  reused  by  client 
software  (multiple  times)  by  declaring 
variables  (external)  to  the  package  and 
using  the  operations  provided  by  the 
package  to  manipulate  these  variables. 

(2)  Abstract  State  Machines:  Provide  sin¬ 
gle  sharable,  "private"  reusable  objects 
and  operations  on  these  objects.  Do 
this  by  encapsulating  types  of  reusable 
objects  in  package  bodies.  This  limits 
client  software  from  declaring  and  using 
multiple  instances  of  the  reusable 
objects  since  their  types  are  hidden. 
Provide  specifications  for  operations  on 
reusable  objects  in  package 
specifications.  Provide  variable  declara¬ 
tions  for  the  reusable  objects  and  imple¬ 
mentations  of  operations  on  the  objects 


in  the  case  where  the  types  of  the  reus¬ 
able  objects  are  not  "composite".  These 
operations  may  contain  parameters  if 
the  types  of  the  reusable  objects  are 
composite,"  and  "atomic"  public  types 
from  which  these  types  are  constructed 
are  declared  in  package  specifications. 
Client  software  can  only  reuse  the 
specific  instances  of  object  abstractions 
contained  in  these  packages.  This 
software  can  only  indirectly  access  the 
variables  implementing  reusable  objects 
through  interfaces  provided  by  visible 
subprograms  specified  in  the  package 
specifications. 

G8-2:  Use  task  declarations  to  specify  inter¬ 
faces  to  reusable  objects.  Use  task  bodies  to 
implement  these  interfaces  and  properties  of 
the  objects. 

This  guideline  is  similar  to  guideline 
G6-3.  For  tasks,  as  compared  to  subpro¬ 
grams,  interfaces  are  concerned  not  only  with 
parameter  passing  but  also  with  synchroniza¬ 
tion.  While  subprograms  can  optionally  have 
a  separate  declaration  and  body,  tasks  must 
have  both  declarations  and  bodies.  Tasks  and 
their  entries,  just  as  subprograms,  should  be 
treated  as  interfaces  to  reusable  objects. 

6.  Example  Ada  Modules 

The  example  Ada  modules  below  are 
taken  from  the  design  of  a  reusable  software 
repository  developed  at  the  Honeywell  Com¬ 
puter  Sciences  Center.  This  repository  sup¬ 
ports  retrieval,  submission,  and  maintenance 
of  categories  of  inventory  items  stored  in  a 
database  management  system.  Its  user  inter¬ 
face  is  menu  oriented.  Specifically,  the 
modules  below  are: 

(1)  a  package  specification  for  the  reposi¬ 
tory  Menu_Manager, 


(2)  a  package  body  for  the  repository 
Menu_Manager,  and 

(3)  a  procedure  subunit  for  one  of  package 

Menu_Manager’s  nested  subprograms, 
Create_Initial_Menu.  The  object 
abstraction  implemented  in  this  package 
is  a  menu  and  associated  menu_stack 
with  operations  including 

Create_lnitial_Menu,  Display_Menu, 
and  Process_Menu-Response.  Package 
Menu_Ma.iager  implements  an  "abstract 
data  type"  by  exporting  menu-oriented 
types  and  operations.  It  also  imple¬ 
ments  an  "abstract  state  machine"  in 
that  it  contains  a  nonexportable  stack  of 
menus  in  its  body. 

In  the  examples,  package  specification 
Menu-Manager  and  the  type  and  procedure 
declarations  contained  in  its  visible  part  are 
directly  reusable.  Its  private  part  type 
declarations  are  indirectly  reusable.  Package 
body  Menu-Manager  is  indirectly  reusable  as 
is  its  nested  data  declarations  and  subpro¬ 
grams.  The  subunit  for  procedure 
Create_Initial_Menu  is  indirectly  reusable 
even  though  it  is  compiled  separately. 

These  example  modules  are  provided 
primarily  to  illustrate  use  of  our  "object- 
oriented"  guidelines  to  write  reusable  Ada 
software.  The  modules  also  illustrate  other 
guidelines  contained  in  our  guidebook,  most 
noticably,  those  pertaining  to  a  standard  form 
for  reusable  software  parts. 


EXAMPLE:  MODULE  1 


with  DAT ABASE_INTERF ACE; 
package  MENU_MANAGER  is 

--  Revision  History:  Created  2/20/86  P.  Stachour 

—  Purpose 

—  Explanation:  Provide  data  structures  for  and  operations  on 

repository  menu  objects. 

--  Keywords:  menu,  menu_manager 

--  Associated  Documentation:  Design  for  Honeywell  Reusable  Software 

Repository 

—  Diagnostics: 

MENU_M AN AGEMENT_ERRO R  :  exception; 

—  Packages:  None 

—  Data  Declarations: 

—  Types: 

type  MENU  is  private; 

type  MENU_NUMBER  is  range  1..100; 

type  MENU  ITEM  is  range  1..55; 

—  Objects:  None 

—  Operations: 

Subprograms: 


procedure  CREATE_INITIAL_MENU  (M_NUMBER  :  out  MENU  NUMBER) ; 

-  Purpose: 

--  Explanation:  Create  initial  repository  menu. 

~  Keywords:  initial_menu,  create_initial_menu. 

-  Parameter  Description: 

-  M_NUMBER  :  Menu  number  associated  with  initial  menu. 

-  Associated  Documentation:  same  as  above. 


procedure  DISPLAY_MENU  (M_NUMBER  :  in  MENU_NUMBER) ; 

-  Purpose: 

-  Explanation:  Displays  specific  menu. 

--  Keywords:  Display_menu. 

--  Parameter  Description: 

--  M_NUMBER  :  Number  of  menu. 

-  Associated  Documentation  :  same  as  above 


y 


procedure  PROCESS_MENU_RESPONSE  (M_NUMBER  :  in  MENU_NUMBER; 
MENU_ITEM_SELECTED  :  in  MENU_ITEM; 

EXIT  :  out  BOOLEAN 

--  Purpose: 

—  Explanation:  Process  response  specified  by  menu  selection. 

This  processing  may  involve  a  call  to 

Display_Menu  and  ACCEPT_MENU  RESPONSE  and  a 

recursive  call  to  PROCESS_MENU_RESPONSE. 

--  Keywords:  menu_response,  process_menu_response. 

--  Parameter  Description: 

--  M_NUMBER  :  Number  of  menu. 

--  MENU_ITEM_SELECTED  :  Specific  item  from  menu  selected. 

—  EXIT  :  Indication  to  exit  menu  system. 

--  Associated  Documentation:  Same  as  above. 


--  Tasks:  None  --  Private: 
private 

type  MENU  is  ...  ; 


end  MENU_MANAGER; 


EXAMPLE:  MODULE  2 


with  INVENTORYJTEM,  CATEGORY,  USER,  TEXTJO; 

with  USER_STATE,  BULLETIN  BOARD,  COMMAND  PROCESSOR,  FILE  SYSTEM, 
SYSTEM  JUPPLIED_UTIL“lTIES; 
package  body  MENU_MANAGER  is 

—  Revision  History:  Created  02/21/86  P.  Stachour 
--  Purpose: 

--  Explanation:  Provide  data  structures  for  and  operations  on 
repository  menu  objects 
--  Keywords:  menu,  menu_manager 

--  Associated  Documentation:  Design  for  Honeywell  Reusable 

Software  Repository 

--  Assumptions/ Resources  Required:  None 
--  Side  Effects:  None 

—  Diagnostics:  None 

—  Packages:  None 
.sp  0.4v 

—  Data  Declarations: 

--  Types: 

type  MENU  ACCESS  is  access  MENU; 
type  MENU~ST  AC  K_EL  EM  ENT  is 
record 

MENU_POINTER  :  MENU_ACCESS; 

MENUJFILESYS_LOCATION  :  STRING  (I. .100); 
end  record; 

-*  Objects: 

MENU  STACK  :  array  (1..31)  of  MENU_STACK  ELEMENT; 

MENU  STACK  INDEX  :  NATURAL  :-0; 

--  Operations: 

Subprograms: 

procedure  CREATE_INITIAL_MENU  (M_NUMBER  :  out  MENU  NUMBER) 

is  separate; 

procedure  DISPLAY  MENU  (M  NUMBER  :  in  MENU_NUMBER)  is  separate; 
procedure  PROCESS'MENU_RESPONSE  (M_NUMBER  :  in  MENU_NUMBER; 

MENUJTEM  SELECTED  :  IN  MENU  ITEM; 

EXIT  ~  :  out  BOOLEAN) 

is  separate; 

.  -  Other  operations  on  MENU-oriented  parameters. 

--  Tasks:  None 

—  Initialization: 


exception 

when  IN VENTOR Y_ITEM .  IN VENTO  R Y _ITEM_ERROR 
when  others  —1 

raise  MENU_MANAGEMENT_ERROR; 
end  MENU_MANAGER; 


EXAMPLE:  MODULE  3 


separate  (MENU  MANAGER) 

procedure  CREATE_INITIAL_MENU  (M_NUMBER  :  out  MENU_NUMBER)  is 

--  Revision  History:  Created  2/21/86  P.  Stachour 
--  Purpose: 

--  Explanation:  Creates  initial  repository  menu  by  reading  data 
for  it  from  a  host  file  and  placing  it  on  the 
MENU_MANAGER  menu  stack. 

--  Keywords:  INITIAL_MENU,  CREATE_INITIAL_MENU 

—  Associated  Documentation:  Design  for  Honeywell  Reusable 

Software  Repository 

--  Parameter  Description: 

—  M_NUMBER  :  Number  of  menu  created. 

--  Assumptions/ Resources  Required:  None 

—  Side  Effects:  None 

—  Diagnostics:  None 
--  Packages:  None 

--  Data  Declarations: 

--  Types:  None 
--  Objects: 

FILE_DESIGNATOR:FILE_SYSTEM.FILE_NAME:  “"DRAOtSOURCElFILE_NAME.TXT"; 

--  Operations: 

--  Subprograms:  None 

—  Tasks:  None 
--  Algorithms: 

begin  -  CREATE_INITIAL_MENU 

-  read  from  host  file,  create  menu,  and  place  on  MENU_S1ACK; 

-  increment  MENU_STACK_INDEX  by  1; 

M_NUMBER  :-  MENU_STACK_INDEX  +  1; 
exception 
when  others  ”1 


end  CREATE_INITIAL_MENU; 


7.  Relationship  To  STARS  Application 
Area 

The  STARS  Application  Area,  in  its 
series  of  Application  Systems  and  Reusability 
Workshops,  is  working  toward  definition  of  a 
reusability  guidebook.  This  work  is  being 
done  by  four  groups:  Part  Taxonomy/ 
Requirements/Metrics,  Incentives,  Library, 
and  System/Design  Integration.  Our  work  at 
Honeywell  on  a  reusability  guidebook  for 
RAPIER  is  relevant  to  the  STARS  reusability 
effort  in  the  following  ways: 

o  Our  guidebook  can  serve  as  the  framework 
for  major  sections  of  the  Application  Area 
guidebook; 

o  Our  reusability  characteristics  compliment 
and  some  areas  extend  the 
Part/Taxonomy/Requirements/Metrics 
Group’s  reusability  model  work  and 
specifically  define  reusable  Ada  (source  code) 
parts; 

o  Our  reusability  guidelines  implicitly  pro¬ 
vide  criteria  for  choosing  reusable  Ada 
software  for  reuse.  They  support  measurable 
reusability  characteristics  and  as  such  can  and 
should  be  the  basis  for  reusability  metrics. 
This  is  also  relevant  to  the 
Part/Taxonomy/Requirements/Metrics 
Group; 

o  Our  reusability  guidelines  provide  a 
methodology  for  building  reusable  Ada 
software  which  is  appropriate  to  the 
System/Design/Integration  Group; 


experiments  and  the  guidebook  review  will 
enable  us  to  evaluate  our  reusability  charac¬ 
teristics  and  guidelines  and  refine  them 
accordingly. 
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Introduction 

Beginning  with  Mcllroy’s  call  for  a 
software  components  industry  (Mcllroy),  dis-  * 
cussions  of  software  reusability  have  been 
strongly  influenced  by  the  compelling  para¬ 
digm  of  hardware  "parts".  While  the  compar¬ 
able  notion  of  discrete  software  "parts"  (in 
the  form  of  programs  or  subroutines)  has 
certainly  had  beneficial  impact  on  the  discip¬ 
line  of  software  engineering,  it  has  also 
tended  to  limit  our  conception  of  reusability 
in  the  context  of  software.  An  important 
message  emerging  from  current  research  and 
in  particular  from  the  STARS  Applications 
Area  Workshops  is  that  design  for  reuse  is  an 
essential  component  of  a  long-term  strategy 
for  software  reusability.  Yet  the  processes  of 
modifying,  transforming  or  generating 
software  components  are  resources  just  as 
reusable  as  the  concrete  software  parts  them¬ 
selves,  if  these  "active  elements"  of  software 
development  can  be  captured  in  the  form  of 
tools  such  as  program  generation  systems 
(Horowitz).  This  reuse  through  regeneration 
effectively  fuses  the  design  and  "manufac¬ 
ture"  of  software  in  ways  that  have  no  clear 
analogies  in  the  hardware  sphere.  (Note, 
though,  that  such  developments  as  silicon 
compilers  and  VLSI  design  libraries  are 
beginning  to  provide  similar  flexibility  in 
hardware  technology.  This  suggests  that 
solutions  to  problems  now  particular  to 
software  reuse  should  eventually  be  applica¬ 
ble  across  the  full  hardware-software  spec¬ 
trum.) 

There  is  currently  much  ongoing 
research  on  a  broad  range  of  technologies, 
from  very  high-level  languages  (VHLls)  to 
automated  software  parts  composition  sys¬ 
tems,  that  could  contribute  significantly  to 
the  overall  goal  of  decreasing  the  amount  of 
hand-written  code  needed  to  implement 


application  programs  (IEEE).  SDC’s  Software 
Technology  Research  and  Development 
department  is  addressing  the  problems  of 
software  reusability  with  a  number  of 
different  programs,  with  particular  focus  on 
program  generation  technology  and  very 
high-level  application-specific  languages,  or 
ASLs.  In  this  report  we  will  describe  some 
of  our  experiences  with  this  technology  and 
its  implications  for  reusability.  We  also  touch 
on  techniques  from  the  field  of  artificial  intel¬ 
ligence,  an  area  that  has  been  less  discussed 
with  regard  to  software  reusability.  The  AI 
(Logic-Based  Systems)  department  at  SDC 
has  developed  some  innovative  approaches  in 
the  area  of  knowledge  representation  and 
expert  systems  development  that  are 
integrally  connected  with  issues  of  software 
reuse. 

General  Approach 

Our  long-term  objective  is  to  develop  a 
methodology  for  identifying  and  characteriz¬ 
ing  potential  high-payoff  domains  for 
software  reuse,  and  a  set  of  criteria  for  select¬ 
ing  the  appropriate  technology,  or  mix  of 
technologies,  to  capture  the  commonality 
within  these  domains.  We  believe  that  cer¬ 
tain  technologies  for  software  reuse  are  best- 
suited  to  application  domains  with  particular 
characteristics.  As  a  starting  point,  we  are 
working  to  define  an  integrating  framework, 
or  taxonomony,  that  usefully  discriminates 
among  diverse  technical  approaches  to 
software  reuse,  including: 

(1)  conventional  techniques  of  reuse  (such 
as  ad-hoc  reuse  and  code  copying, 
language  features  supportive  of  reusa¬ 
bility,  and  software  libraries) 

(2)  application-specific  languages  and  appli¬ 
cation  generators 


(3)  knowledge-based  or  expert  systems 

(4)  various  hybrids  of  the  above  approaches 

Today  lists  and  arrays  are  standard 
alternative  data  structures  that  one  selects  for 
use  based  on  criteria  such  as  time/space 
tradeoffs  and  mode  of  access.  As  alternative 
reusability  technologies  mature,  the  choice  of 
a  library  of  discrete  software  parts,  an  appli¬ 
cation  generator  or  an  expert  system  will 
similarly  be  made  on  the  basis  of  characteris¬ 
tics  and  requirements  of  the  intended  applica¬ 
tion  domain.  After  briefly  describing  our 
work  in  these  areas,  we  will  offer  some  tenta¬ 
tive  conclusions  about  useful  criteria  for 
evaluating  the  proper  ’fit’  between  application 
domains  and  key  technologies. 


services.  There  are  a  number  of  common 
features  to  the  applications  where  this 
approach  has  succeeded: 

(1)  The  libraries  are  organized  around 
specific  application  domains. 

(2)  There  are  standard  interfaces,  calling 
and  naming  conventions  that  effectively 
make  the  library  a  uniform  set  of  ser¬ 
vices. 

(3)  The  routines  in  the  library  encode 
operations  for  which  there  is  a  known 
and  fairly  standard  algorithm.  The 
functionality  of  the  routine  does  not 
vary  depending  on  dynamic  characteris¬ 
tics  of  the  point  of  call. 


Conventional  Approaches  to  Software 
Reusability 

Conventional  approaches  to  software 
reusability  seek  to  reduce  the  amount  of  code 
that  must  be  written  by  hand  by  isolating 
fragments  of  application  software  as  pieces 
that  can  be  shared  and  reused  by  many 
specific  applications.  This  kind  of  reuse  can 
occur  in  ceveral  forms,  including  ad-hoc 
reuse  of  code  (sometimes  called  "scaveng¬ 
ing"),  use  of  language  features  that  are  sup¬ 
portive  of  software  reuse,  and  software 
libraries. 

There  are  severe  difficulties  with  ad-hoc 
reuse  (i.e.,  reuse  of  a  component  that  was 
not  written  with  reuse  in  mind)  that  nullify 
most  benefits  associated  with  true  reusability. 
It  is  hard  to  estimate  the  amount  of  time  and 
effort  involved  in  modifying  the  code  for  a 
new  application,  or,  in  fact,  whether  it  would 
be  cheaper  to  write  the  code  from  scratch. 
Subtle  discrepancies  between  the  require¬ 
ments  of  the  original  and  the  retargeted 
application  can  lead  to  decreased  reliability  or 
efficiency  of  the  final  system.  Nevertheless, 
for  some  situations  ad-hoc  reuse  may  be 
cost-effective,  particularly  when  there  is  not 
much  potential  for  recurring  applications,  or 
when  requirements  of  the  new  application 
can  be  modified  to  accomodate  less  flexible 
features  of  the  original  application. 

Libraries  of  standard  subroutines  have 
achieved  some  success  in  certain  application 
domains,  such  as  mathematical  routines, 
graphics  packages,  or  operating  system 


There  are  a  number  of  critical  issues  to 
be  faced  in  developing  large  libraries  of  reus¬ 
able  software  components,  problems  such  as 
configuration  control  quality  assurance, 
cataloguing  and  documentation.  The 
definition  of  syntactic  and  semantic  interfaces 
is  one  of  the  main  technical  barriers  to  the 
effective  reuse  of  software  (Batz83).  Though 
it  is  easy  to  think  of  software  libraries  as 
"current"  or  certainly  "near-term"  technology, 
developing  libraries  on  a  large  enough  scale 
to  really  impact  productivity  will  push  the 
state  of  the  art,  especially  of  database  tech¬ 
nology,  as  hard  as  program  generation  tech¬ 
niques. 

Besides  the  problems  stemming  from 
inadequate  technology,  there  are  also 
domains  where  maintaining  a  library  of  con¬ 
crete  software  subroutines  is  not  a  good  fit 
with  the  requirements  of  the  domain.  One 
example  is  simple,  low-level  functions  that 
require  tailoring  according  to  a  large  number 
of  parameters.  If  the  options  for  selecting 
the  right  version  of  the  routine  vary  orthogo¬ 
nally,  one  could  quickly  wind  up  with  an 
exponential  number  of  components  to  be 
stored  in  the  library.  Some  form  of  program 
generation  from  specifications  is  needed  for 
these  applications. 

Admittedly,  many  problems  associated 
with  ad-hoc  reuse  or  standard  subroutine 
libraries  have  been  addressed  by  advanced 
features  of  Ada*,  which  was  designed  with 
reusability  as  a  clear  priority.  SDC  is  directly 
supporting  the  Ada  movement  through  the 
formulation  of  Ada-based  methodologies. 


studies  in  reusable  Ada  components, 
development  of  Ada  tools,  automatic  genera¬ 
tion  of  Ada  software  from  a  high-level 
specification  and  active  participation  in  the 
Ada  community. 

The  use  of  Ada  features  such  as  pack¬ 
ages,  generics,  strong  typing,  default  parame¬ 
ters,  and  tasking  to  support  reusability  have 
been  described  extensively  elsewhere.  These 
features  of  Ada  have  significantly  extended 
the  domains  in  which  reuse  of  static  software 
components  will  be  viable.  It  is  interesting  to 
note,  for  example,  that  features  such  as  gen¬ 
eric  program  units  have  shifted  functionality 
onto  the  Ada  compiler  that  previously  would 
have  required  program  generation  techniques. 
However,  because  Ada  has  been  standard¬ 
ized,  any  further  extensions  to  these  facilities 
for  generating  Ada  code  at  compile  time  can¬ 
not  be  part  of  the  Ma  compiler  per  se. 

Application-Specific  Very  High-Level 
Languages 

Application-specific  languages  (very 
high  level  languages  that  are  designed  for  a 
particular  application  area)  offer  a  useful  pro¬ 
grammatic  interface  to  reusable  software 
modules.  Such  a  language  can  act  as  a 
tailored  query  language  for  accessing  a  reposi¬ 
tory  of  reusable  algorithms  within  a  narrow 
domain,  as  an  automated  parts-composition 
system,  linking  together  static  routines  from 
a  library,  or  as  a  parts-generation  system, 
creating  instances  of  a  given  subroutine 
optimized  to  the  requirements  of  each 
instance  of  use.  Thus  it  can  provide  both  the 
flexibility  and  generality  of  a  highly 
parameterized  set  of  routines,  and  the 
efficiency  of  tailored  code. 

ASLs  will  have  highest  pay-off  in  nar¬ 
rowly  focused  applications  areas  where  many 
slightly  customized  versions  of  a  single  basic 
program  are  created  from  large,  well- 
understood  libraries  of  basic  functions 
(Standish).  ASLs  permit  the  direct  embed¬ 
ding  of  application-specific  methodology  in 
the  generation  system.  ASLs  can  be  easier 
for  both  programmers  and  computer-naive 
application  specialists  to  use  than  general- 
purpose  high-level  languages,  because  they 
allow  tasks  to  be  specified  in  a  non¬ 
procedural  language  close  to  the  terminology 
of  the  application  domain.  In  addition,  they 


allow  typical  sequences  of  actions  to  be 
specified  at  a  higher  level.  Arguments  that 
must  be  provided  explicitly  in  a  call  to  a 
library  subroutine  may  be  taken  implicitly 
from  context  in  an  ASL  specification.  Also, 
an  ASL  processor  can  perform  more  exten¬ 
sive  static  checks  for  semantic  validation  than 
is  possible  with  embedded  subroutine  calls. 
Thus,  an  AS!  is  a  particularly  useful  inter¬ 
face  to  a  set  of  services  providing  access  to  a 
persistent  data  structure  such  as  a  database, 
where  there  are  strict  integrity  constraints  on 
allowable  sequences  of  operations.  The  syn¬ 
tax  of  the  ASL  can  disallow  invalid  sequences 
of  operations  that  would  have  to  be  defected 
at  run-time  if  called  as  a  sequence  of  subrou¬ 
tine  calls  from  a  general-purpose  program¬ 
ming  language. 

We  believe  ASLs  are  a  more  feasible 
near-term  alternative  than  very  high-level 
general-purpose  specification  languages 
(Cheatham).  Because  ASLs  use  application 
terminology,  they  are  less  abstract,  hence 
easier  to  use  and  maintain  than  formal  or 
algebraic  specifications. 

An  ASL  is  useful  by  virtue  of  its  close 
connection  with  domain  terminology  of  the 
target  domain,  its  narrow  focus,  its  non¬ 
procedural  level  of  specification,  and  the 
guaranteed  correctness  of  its  transformation. 
Languages  of  this  sort  can  serve  as  the  input 
specification  to  two  kinds  of  generation  sys¬ 
tems: 

(1)  a  highly-parameterized  generic  applica¬ 
tion  program,  which  simulates  the 
behavior  of  many  special-purpose  appli¬ 
cations  by  performing  sophisticated 
run-time  decision-making; 

(2)  an  application  generator,  which 
transforms  the  specification  into  a 
tailored  application  program  in  a  lower- 
level  programming  language. 

*Ada  is  a  registered  trademark  of  the 
U.S.  Government.  (AJPO) 

In  practice,  the  two  options  are  similar, 
except  that  the  former  embeds  the  generation 
expertise  at  compile  time,  the  latter  chooses 
the  proper  actions  at  run-time.  A  compiled 
implementation,  or  application  generator, 
might  be  more  suitable  for  stable  applications 
that  will  be  run  with  exactly  the  same 


parameters  a  number  of  times.  Also,  since 
the  output  of  an  application  generator  need 
not  be  a  program  in  the  ordinary  sense,  appli¬ 
cation  generators  can  be  useful  in  generating 
multiple  output  hies  that  must  be  kept  syn¬ 
chronized  from  a  single  high-level 
specification.  An  interpreted  implementation 
is  more  appropriate  for  interactive  develop¬ 
ment  of  specifications  and/ad-hoc  or  one¬ 
time  usages  of  the  generation  system.  We 
refer  to  both  highly  parameterized  applica¬ 
tions  and  application  generators  as 
application-specific  languages  ( ASLs) , 
because  the  use  of  high-level  terminology 
from  the  application  domain  is  a  common 
strategy  of  both  approaches. 

A  Meta-Generator  for  ASL  Systems 

For  many  DoD  applications,  the 
development  of  application-specific  languages 
is  technologically  feasible,  but  the  develop¬ 
ment  cost  has  seemed  prohibitive.  These 
development  costs  are  steadily  decreasing, 
however,  as  compiler  specification  and  gen¬ 
eration  techniques  approach  the  stage  where 
entire  tools  in  the  language-processing 
domain  can  be  automatically  generated  from 
their  specifications.  SDC  has  developed  a 
generation  system  for  tool-building  known  as 
the  Syntax  and  Semantic  Analysis  and  Gen¬ 
eration  System  (SSAGS),  a  Ada-based  gen¬ 
eration  system  based  on  attribute  grammars 
(Knuth).  Integrated  with  a  standard  lexical 
analyser  generator  and  parser  generator, 
SSAGS  accepts  and  validates  an  attribute 
grammar  specification  of  the  semantics  of  a 
language,  and  automatically  generates  a 
semantic  evaluator  for  the  specified  language. 

SSAGS  provides  many  advantages  for 
the  implementation  of  ASLs.  The  use  of 
attribute  grammars  within  SSAGS  permits 
the  specification  of  language  semantics  in  a 
very  clear  -  and  hence  less  error-prone  - 
fashion.  In  addition,  SSAGS  is  based  on 
ordered  attribute  grammars  (Kastens),  a  re¬ 
stricted  class  of  attribute  grammars  that  allow 
a  language  specifiction  to  be  statistically 
checked  for  valid  semantics.  To  take  full 
advantage  of  this  static  validation,  SSAGS 
functions  as  an  application  generator  in  the 
sense  described  above,  unlike  some  interac¬ 
tive  attribute-grammar  based  systems  such  as 
the  Cornell  Program  Synthesizer  (Teitei- 
baum81).  Thus  translators  implemented  in 


SSAGS  require  less  interactive  debugging  and 
can  be  maintained  from  single,  reusable 
specifications.  SSAGS  has  successfully  been 
used  to  produce  several  translators,  including 
an  Ada-to-Diana  translation  system  and  a 
configuration  ASL  for  Burroughs  XE550  sys¬ 
tems.  We  are  currently  using  SSAGS  to 
implement  an  ASL  for  message  format  vali¬ 
dation  in  the  message  processing  domain.  In 
addition,  .  the  SSAGS  translator  itself  is 
specified  in  and  generated  by  SSAGS.  We 
believe  that  use  of  a  translator  generator  sys¬ 
tem  like  SSAGS,  together  with  the  strategy 
of  defining  small  languages  for  narrowly 
defined  domains  is  a  key  to  the  cost-effective 
implementation  of  ASLs  for  reusability. 


Expert  Systems 

In  the  context  of  software  reusability, 
domain  analysis  usually  involves  examining  a 
collection  of  application  programs  addressing 
a  similar  class  of  problems  (e.g.,  air  traffic 
control  or  business  systems)  in  order  to  iden¬ 
tify  potential  reusable  software  components 
or  algorithms  (CAMP).  It  may  seem  out  of 
place  to  discuss  expert  systems  technology  in 
this  context.  Typically,  expert  systems  auto¬ 
mate  what  was  previously  a  largely  human 
activity;  domain  knowledge  is  gleaned  from 
human  experts  and  often  can’t  be  reduced  to 
deterministic  algorithms.  Hence,  there  is  less 
likely  to  be  a  body  of  conventional  programs 
supporting  an  application  domain  being  con¬ 
sidered  for  expert  system  support. 

But  the  presence  of  conventional  appli¬ 
cations  is  not  a  dependable  indicator  of 
whether  an  expert  system  approach  is  most 
appropriate  for  a  domain.  A  currently  unau¬ 
tomated  application  area  may  be  quite  amen¬ 
able  to  conventional  software  techniques  (or 
may  not  be  worth  automating  at  all).  Con¬ 
versely,  for  some  problem  domains  currently 
supported  by  conventional  software  a 
significant  increase  in  software  reuse  may  not 
be  feasible  through  a  parts-library  or  program 
generation  approach  alone.  Knowledge-based 
techniques  and  heuristics  may  be  the  level  at 
which  commonality  can  best  be  factored  into 
the  domain. 

For  example,  if  choice  of  the  appropri¬ 
ate  algorithm  for  a  given  problem  situation 
requires  extensive  jemantic  knowledge  of  the 


application  domain,  knowledge  representation 
techniques  may  be  the  most  suitable  way  of 
encoding  this  knowledge.  In  another  case, 
the  performance  needs  of  the  domain  may  be 
stringent  enough  that  subroutines,  to  be 
usable,  must  be  optimized  for  the  point  of 
use.  In  such  domains,  knowledge-based  pro¬ 
gram  synthesis  or  program  transformations 
may  be  a  prerequisite  to  effective  use  of 
software  parts.  Note  that  these  situations 
might  utilize  knowledge-based  technology  in 
two  very  different  ways. 

(1)  Artificial  intelligence  techniques  and 
languages  may  be  directly  used  within 
the  system  being  developed. 

(2)  Artificial  intelligence  techniques  may  be 
used  in  combination  with  library  access, 
program  generation,  parts  composition 
to  facilitate  reuse  of  conventional 
software. 

In  either  case,  expert  systems  provide 
reusability  in  ways  that  are  not  available  with 
other  techniques.  (We  will  avoid  discussion 
of  functional  or  logic  programming  language 
features  that  support  reuse,  since  these 
advantages  would  be  confined  to  direct  AI 
applications.) 

Knowledge-based  technique  provide  a 
means  of  isolating  domain  commonality  at  a 
more  abstract  level  than  that  of  concrete  sub¬ 
routines,  or  even  standard  algorithms  and 
procedures.  This  allows,  at  least  potentially, 
a  separation  of  procedural  from  declarative 
knowledge  which  is  difficult  to  achieve  in 
conventional  programming  languages.  It  has 
also  been  difficult  to  achieve  this  separation 
in  many  "traditional"  expert  systems,  which 
are  implemented  as  large,  unstructured  sets 
of  rules  combining  conditions  and  actions  in 
a  single  framework.  KNET  (Freeman83),  a 
semantic  network  knowledge  representation 
system  developed  by  SDC,  has  several 
features  that  help  to  partition  semantic  and 
domain-specific  knowledge--  the  model  of  the 
domain—  from  the  logic  of  applications  mak¬ 
ing  procedural  use  of  that  knowledge.  SDC 
has  used  KNET  to  implement  a  large  expert 
system  for  the  automatic  configuration  of 
Burroughs  computer  equipment  (Free- 
man85).  The  system  is  intended  to  support 
both  the  product  experts  (the  plant 
engineers),  who  create  and  modify  the 


knowledge  bases  about  various  Burroughs 
systems  products,  and  the  sales  personnel 
who  use  the  automated  configurator  applica¬ 
tion  to  prepare  complete  and  accurage 
configurations  for  customers.  The  same 
knowledge  base  used  by  the  configurator 
application  could  potentially  be  used  for 
diverse  applications,  including  design  revi¬ 
sion,  manufacturing  scheduling,  system  pric¬ 
ing  and  maintenance.  Though  there  may  be 
little  procedural  commonality  between  the 
various  applications,  we  gain  reusability  by 
consolidating  common  domain  knowledge  in 
an  independent  structure.  While  this  is  not 
software  reuse  in  a  strict  sense,  it  is  an 
effective  reuse  of  knowledge  that  would  more 
traditionally  be  embedded  in  application 
software  (and  hence  rewritten  anew  for  each 
application). 

This  separation  also  allows  different 
domain  experts  to  model  individual  parts  of 
the  system  independently.  Here  the  domain 
model  turns  out  to  share  some  of  the  advan¬ 
tages  we  associate  with  ASLs:  because  the 
domain  model  is  defined  in  non-procedural 
terms,  it  is  easier  for  the  model  to  be 
independently  maintained  or  created  by  appli¬ 
cation  specialists  who  are  not  expert  systems 
developers. 

Just  as  many  applications  can  use  one 
knowledge  base,  an  application  can  be  written 
to  work  off  multiple  knowledge  bases.  For 
example,  the  functionality  of  the  Burroughs 
configurator  can  be  extended  without  modify¬ 
ing  the  application,  by  creating  a  model  of  a 
new  system  component.  This  is  closer  to  our 
intuitive  notion  of  software  reuse,  since  the 
application  can  be  adapted  in  a  well  managed 
way  to  different  situations  of  use. 

Extending  Domain  Analysis  for  Technology 
Selection 

Our  work  in  both  program  generation 
technology  and  knowledge-based  systems  has 
revealed  a  number  of  similarities  in  the 
domain  analysis  process  for  these  respective 
areas,  as  well  as  similarities  to  domain 
analysis  performed  for  the  development  of 
more  conventional  software  parts  technology 
as  well  (CAMP).  This  suggest  that  selection 
of  appropriate  technology  for  an  application 
domain  is  best  done  in  parallel  with  domain 
analysis.  and  that  the  domain  analysis  process 


should  be  refined  and  extended  to  produce 
information  relevant  to  this  task. 

A  basic  model  for  assessing  the  poten¬ 
tial  benefit  of  designing  for  reuse  must  pro¬ 
vide  a  trade-off  of  the  cost  of  the  initial 
implementation,  the  projected  number  of 
future  usages  for  the  function,  the  average 
cost  of  each  adaptation  for  reuse,  and  the 
cost  of  re-implementing  rather  than  reusing 
for  these  instances.  Domain  analysis  to  sup¬ 
port  technology  assessment  must  consider 
many  additional  factors.  The  domain  analyst 
must  look  for  commonality  at  different  levels 
of  abstractions  and  different  phases  of  the 
software  life  cycle,  and  must  look  for  com¬ 
mon  development  activities  and  transforma¬ 
tions  as  well  as  common  static  components. 
The  following  list  is  an  initial  set  of  questions 
that  might  be  part  of  this  process. 

(1)  For  a  typical  application  program,  what 
proportion  of  the  processing  consists  of 
functions  from  the  target  domain?  If 
applications  tend  to  be  predominantly 
invocations  of  doman  functions,  (e.g., 
database  querying  and  reporting),  an 
ASL  might  be  appropriate.  If  domain 
functions  are  sparsely  distributed,  a 
library  might  be  better.  If  the  relative 
proportions  of  reuse  ranges  widely 
within  the  applications,  a  layered 
approach  offering  both  direct  interface 
to  the  library  routines  and  an  ASL  shell 
may  be  indicated.  (For  example,  most 
database  systems  provide  both  an 
embedded  programmatic  interface  to 
database  services  and  an  independent 
query  language,  which  may  be  inter¬ 
preted  or  compiled.) 

(2)  For  a  given  category  of  reusable  parts, 
how  large  would  the  necessary  library  of 
parts  be?  Would  sophisticated  catalogu¬ 
ing  or  pattern- matching  tools  be 
required  to  find  the  right  routine  in  the 
library?  If  the  size  or  complexity  of  the 
library  passes  a  certain  threshold,  usage 
will  drop  because  of  retrieval  effort.  In 
this  situation,  it  might  be  better  to  par¬ 
tition  the  library  into  smaller  packages, 
or  encapsulate  some  sets  of  routines 
with  an  automated  part  selection 
mechanism  accessed  by  an  ASL. 


component  variation  (time/space, 
parameterization,  binding  mechanism)? 
For  example,  are  components  accessed 
as  procedures,  functions,  tasks,  or 
stand-alone  programs,  or  a  mix  of 
these?  If  usage  patterns  are  clustered 
along  one  axis,  generation  techniques 
may  be  appropriate.  If  usage  needs 
vary  widely,  creation  as  needed  and 
storage  in  the  library  might  make  most 
sense. 

(4)  Are  the  parameter  choices  for  a  routine 
"flat"  or  "tree-structured"?  A  subrou¬ 
tine  requires  a  fixed  number  of.  parame¬ 
ters  (though  defaults  can  be  provided  as 
in  Ada).  An  ASL  has  more  flexibility 
over  parameter  choices,  but  will  still 
require  the  inputs  in  a  batch  mode.  An 
expert  system  application  could  prompt 
intelligently  and  constrain  choices 
further  in  the  process  as  a  result  of  pre¬ 
vious  decisions. 

(5)  How  deterministic  are  the  functions 
common  to  the  domain?  Are  they 
definable  directly  as  functions  in 
software,  deterministic  algorithms  that 
can  be  incorporated  in  a  generation  sys¬ 
tem,  or  a  set  of  rules,  procedures  and 
heuristics,  for  which  an  expert  system 
might  be  an  appropriate  implementa¬ 
tion? 

(6)  How  critical  is  the  efficiency  of  the  final 
code?  If  performance  is  not  critical 
(such  as  in  prototyping  environment) 
conventional  parts  may  be  sufficient.  If 
performance  constraints  are  high,  but 
parameterization  does  not  vary  widely, 
it  may  still  be  feasible  to  store  discrete 
optimized  parts,  but  more  ancillary 
descriptions  of  optimization  priorities 
and  benchmarks  will  need  to  be  main¬ 
tained  along  with  the  software  part.  If 
both  performance  and  flexibility  are 
required,  program  generation  tech¬ 
niques  may  be  required  to  achieve  ade¬ 
quate  reuse. 

(7)  How  modifiable  are  the  system  require¬ 
ments?  Is  the  customer  willing  to 
change  specifications  to  suit  existing 
characteristics?  If  so,  conventional 
reuse  techniques  will  be  more  applica¬ 
ble. 


(j;  What  is  the  expected  distribution  of 
usage  along  the  various  dimensions  of 


This  list  is  by  no  means  a  complete  set 
of  criteria  for  evaluation;  nor  are  the 


interpretations  of  the  criteria  iron-clad.  The 
eventual  goal  would  be  a  set  of  guidelines 
that  a  software  manager  could  apply  when 
considering  the  (re)automation  of  a  specific 
domain,  in  order  to  choose  the  appropriate 
technology. 

Hybridizations  of  technologies 

Near-term  (application-specific)  techno¬ 
logies  for  software  reuse,  whether  software 
libraries  or  ASLs,  will  cover  only  a  small  pro¬ 
portion  of  the  large-scale,  real-time  applica¬ 
tions  of  most  concern,  because  these  systems 
represent  the  intersection  of  multiple  applica¬ 
tion  domains  (in  the  restricted  sense 
described  above),  at  disparate  levels  of  for¬ 
malization  and  standardization. 

This  does  not  mean  that  technologies 
for  software  reusability  can  have  only  an 
incremental  impact  on  large  system  develop¬ 
ment  in  the  near  term.  To  achieve  an  impact 
on  these  systems  adequate  to  the  productivity 
goals  of  the  STARS  program,  it  is  necessary 
to  support  a  mix  of  horizontal  and  vertical 
domains;  that  is,  both  domains  defined  in 
terms  of  application  areas  in  the  real  world 
(communications,  air  traffic  control,  etc.), 
and  those  that  cut  across  traditional  applica¬ 
tion  boundaries,  such  as  mathematical  sub¬ 
routines,  manipulation  of  data  structures,  or 
support  of  software  development  activities. 
This  strategy  plays  a  key  role  in  our  plans  to 
incorporate  ASLs  as  an  integral  component  of 
SDC’s  Common  Software  Environment 
(SDC-CSE)  (SDC85).  We  plan  to  define 
ASLs  tailored  to  several  "axes"  within  the 
environment;  <T)  project  roles  associated  with 
software  life  cycle  phases  (programmer, 
designer,  requirements  analyst)  and  skill  lev¬ 
els;  (2)  architectural  features  of  the  environ¬ 
ment  (such  as  database  interaction,  project 
communication,  or  configuration  manage¬ 
ment);  and  (3)  additional  ASLs  supporting 
the  specific  application  area  of  the  project. 

Because  different  domains  are  best 
suited  for  particular  technical  approaches,  this 
mix  of  domains  must  be  supported  by  pro¬ 
moting  alternative  technologies  with  the  most 
potential  for  near-term  cost-effectiveness, 
and  developing  techniques  for  the  hybridiza¬ 
tion  of  these  technologies  wherever  possible. 
For  example,  application  generators  have 
been  most  successfully  used  for  areas  like 


database  management,  where  typical  pro¬ 
grams  do  little  but  access  the  database  and 
present  the  data.  They  are  currently  less 
suitable  for  domains  where  generated  func¬ 
tionality  is  interspersed  with  arbitrary  compu¬ 
tation.  Techniques  for  infiltrating  code  pro¬ 
duced  by  application  generators  with  hand¬ 
written  code  (or  vice  versa)  would  greatly 
expand  the  scope  of  use  for  these  tools 
(Volkenburgh).  Similarly,  libraries  of  reus¬ 
able  software  should  be  designed  to  accom¬ 
modate  the  inclusion  of  hand-written  com¬ 
ponents  and  automatically  generated  or 
transformed  components  in  a  uniform  (and, 
to  some  degree,  caller-transparent)  manner. 

The  integration  of  specification  and 
generation  techniques  with  reusable  software 
parts  could  facilitate  effective  reuse  of  these 
parts.  When  a  software  component  library 
achieves  a  sufficient  complexity  one  or  more 
ASLs  could  be  defined  as  a  natural  and 
efficient  user  interface  to  the  library.  The 
selection  of  software  parts  is  automatically 
performed  by  the  generation  system,  which 
does  so  on  the  basis  of  its  built-in  knowledge 
of  the  syntax  and  semantics  of  the  software 
parts.  Usages  of  the  reusable  software  parts 
are  linked  by  code  automatically  generated 
from  the  specification.  This  method  guaran¬ 
tees  correct  and  effective  usage  of  the  reus¬ 
able  parts.  By  allowing  both  access  to  the 
ASL  interface  and  direct  access  to  the  under¬ 
lying  library  of  routines,  maximum  flexibility 
will  be  available  when  required;  the  ASL  can 
be  cleaner,  since  it  will  not  have  to  accom¬ 
modate  as  many  pathological  ’special  cases’. 

Finally,  we  see  great  potential  for  the 
application  of  knowledge-based  techniques  to 
parts  composition,  generation,  catalogueing 
and  tailoring  systems.  We  believe  the 
appropriateness  of  this  technique  will  increase 
as  more  expertise  is  gained  with  conventional 
parts  management  systems  technology. 

General  Issues 

Advancing  our  understanding  of 
appropriate  matching  of  reuse  technology  to 
application  domains  is  not  going  to  solve  all 
the  difficult  issues  involved  in  reusing 
software.  Designing  for  reuse  is  inherently 
more  complex  than  writing  special-purpose 
applications,  because  one  sets  out  to  solve  a 
class  of  problems  rather  than  one  specific 


problem.  Thus,  we  should  anticipate  that 
each  technology  will  present  its  own  chal¬ 
lenges  in  design.  But  also,  certain  problems 
that  have  been  encountered  in  software  com¬ 
ponents  technology  may  reappear  at  a 
different  level  with  application  generators  or 
expert  systems.  In  the  interest  of  a  realistic 
perspective  technologies  to  solve,  we  offer  a 
few  issues  that  appear  common  to  all  the 
approaches  described  above. 

Application  Specificity 

Software  reusability  becomes  more 
feasible,  regardless  of  the  technology 
involved,  in  direct  proportion  to  the 
software’s  degree  of  specificity  to  a  particular 
application  domain.  This  is  confirmed  by  the 
domains  in  which  subroutine  libraries  have 
been  most  successful,  such  as  libraries  of 
mathematics,  graphics,  or  operating  system 
routines.  The  critical  problems  in  library 
configuration  management,  cataloguing  and 
retrieval  quickly  push  the  state  of  the  art 
when  the  scope  or  complexity  of  the  library 
gets  too  large.  This  is  also  a  key  to  the  strat¬ 
egy  of  very  high-level  application-specific 
languages  in  contrast  to  attempts  to  define 
general-purpose  high-level  specification 
languages.  By  confining  language  scope  to 
small,  clearly  defined  domains,  it  is  possible 
for  ASL  processors  to  generate  efficient  code 
of  production  quality.  Finally,  this 
observation  is  consistent  with  the  general 
thrust  in  the  expert  systems  area  toward  con¬ 
centration  on  domain-specific  expertise  rather 
than  general  knowledge  or  problem-solving. 

Separation  of  Volatile  from  Stable  Informa¬ 
tion 

One  limiting  factor  to  capturing  com¬ 
monality  in  a  domain  is  the  relative  degree  of 
volatility,  or  frequency  of  change,  of  the 
information  in  the  domain.  For  example, 
one  does  not  want  to  embed  monthly  pricing 
information  in  a  program  generation  system 
that  would  have  to  be  recompiled  with  each 
price  shift.  Though  the  rules  used  in 
knowledge-based  systems  might  appear  to 
support  this  sort  of  change  better  than  a  com¬ 
pilation  system,  it  would  appear  that  a 
knowledge-based  application  of  any  size  and 
longevity  also  needs  an  auxiliary  mechanism 
to  handle  rapidly  changing  knowledge.  The 


AI  department  at  SDC  has  been  involved 
with  work  on  linking  knowledge  bases  with 
loosely  coupled  conventional  databases  to 
achieve  the  necessary  separation  of  volatile, 
time-dependent  information  from  more 
stable  domain-dependent  knowledge.  Viewed 
in  this  way,  the  database  in  effect  functions 
as  an  extremely  flexible  and  maintainable  sys¬ 
tem  for  passing  a  large  number  of  parameters 
to  the  system.  A  program  generation  system 
or  a  software  parts  composition  system  could 
make  use  of  the  same  sort  of  faciltity. 

Modularity 

The  need  for  modularity  in  large  sys¬ 
tems  is  not  allayed  by  the  introduction  of 
ASLs,  component  libraries  or  expert  systems. 
Instead,  it  reasserts  itself  at  new  levels  of 
abstraction.  Libraries  should  be  partitioned 
into  intuitively  cohesive  collections  of  ser¬ 
vices,  modularized  according  to  the  same 
principles  of  good  software  engineering  that 
are  helping  to  make  hand-written  software 
tractable.  (This  conforms  with  the  state  of 
practice  in  the  standard  C  libraries  of  UNIX*, 
or  the  intention  of  the  package  mechanism  in 
Ada.) 

We  have  advocated  the  creation  of 
small  narrowly  defined  ASLs  rather  than  new 
large,  general-purpose  languages  (since  our 
purpose  is  not  to  reinvent  Ada).  In  a 
environment  where  production  of  special- 
purpose  languages  for  software  development 
has  become  economically  justifiable,  we  must 
begin  to  modularize  the  languages  in  our 
environment  with  the  same  care  that  we 
create  reusable  subroutines.  By  keeping 
ASLs  small,  cohesive  and  single-function,  we 
increase  the  ways  in  which  these  languages 
can  be  linked  together  to  form  new  tools. 
We  are  currently  investigating  the  theoretical 
problems  in  specifying  shareable  sublanguage 
ASLs  that  can  be  reused  in  different  con¬ 
texts.  For  example,  an  ASL  for  string  pat¬ 
tern  matching  might  be  used  within  many 
other  ASLs.  We  should  be  able  to  define  it 
as  a  separate  language  and  invoke  it  as  such 
from  other  language  specifications.  Finally, 
modularity  in  knowledge  bases  is  a  key  to  the 
tractability  of  large  expert  systems,  as  we 
have  seen. 

One  implication  of  this  recurring  modu¬ 
larity  is  that  components  management  will  be 


needed  at  all  levels  in  a  hybrid  technology 
environment.  ASLs  will  need  to  be  main¬ 
tained,  catalogued  and  reused  just  as  we 
currently  propose  for  subroutines.  Further 
down  the  pike,  knowledge  bases  themselves 
might  reside  in  libraries  as  well. 

Maturity  of  Domain  Knowledge 

The  technology  suitable  to  an  applica¬ 
tion  domain  depends  closely  on  the  relative 
maturity  and  stability  of  the  domain,  and  the 
presence  of  a  firm  basis  for  standardization 
and  the  consolidation  of  expertise.  This  is 
borne  out  of  examples  such  as  the 
widespread  use  of  application  generators  for 
well-understood  domains  such  as  business 
software,  and  the  successful  libraries  of  stan¬ 
dard  routines.  This  implies  that  efforts  to 
introduce  software  libraries  or  application 
generators  in  highly  unstable  or  innovation¬ 
intensive  software  development  environ¬ 
ments  may  constitute  a  premature  introduc¬ 
tion  of  reuse  technology.  It  may  result  in 
simple  wasted  effort  or  premature,  hence 
ineffectual  standardization.  Instead,  we  advo¬ 
cate  the  incremental  and  evolutionary 
approach  of  initic'ly  tackling  narrowly 
defined,  highly  constrained  and  well- 
understood  sub-domains  within  such  applica¬ 
tion  areas.  In  this  phase,  library  support  or 
ASL  support  might  be  equally  feasible 
depending  on  the  profile  of  the  domain.  As 
our  knowledge  of  an  application  domain 
matures,  we  will  evolve  naturally  through  a 
progression  of  technologies  to  support  reuse, 
beginning  with  ad-hoc  reuse,  continuing 
through  development  of  standard  libraries  of 
routines  for  common  functions,  then 
automating  the  composition  of  these  func¬ 
tions  through  higher-level  application  genera¬ 
tors,  to  eventual  knowledge- based  support. 
This  corresponds  with  the  evolution  in  data¬ 
base  technology,  which  may  serve  as  the  clas¬ 
sic  example  (to  date)  of  a  reuse-intensive 
software  domain. 

Conclusion 

The  taxonomy  of  reusability  technolo¬ 
gies  and  criteria  for  domain  presented  here 
are  initial  suggestions.  Much  work  needs  to 
be  done  to  make  this  framework  into  a 
comprehensive  methodology  that  can  be  of 
general  use  within  the  indistry,  though  there 
is  already  a  large  body  of  experience  to  guide 


this  work.  This  knowledge  should  be  consol¬ 
idated  and  codified,  through  industry-wide 
forums  for  discussion  such  as  the  STARS 
Applications  Area  Workshop.  Once  some 
consensus  has  been  reached  on  the  dependa¬ 
bility  of  these  criteria,  the  proposed  STARS 
Reusability  Guidebook  would  be  an  excellent 
avenue  for  making  these  guidelines  available 
to  the  software  industry  as  a  whole. 

‘UNIX  is  a  registered  trademark  of  AT&T 
Bell  Laboratories. 
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Introduction 


The  primary  objective  of  this  set  of  notes  is  to  make  the  audience  aware  of  some  of  the 
more  important  issues  relating  to  the  creation  of  reusable  Ada  software.Specifically,  these 
notes  are  designed  to  touch  upon  the  “nuts  and  bolts”  issues.  Since  the  time  allotted  for 
presentation  is  less  than  one  day,  the  material  is  intentionally  brief.  It  is  assumed  that  the 
audience  has  at  least  a  reading  knowledge  of  the  Ada  programming  language,  and  has 
developed  at  least  one  piece  of  serious  software. 

Some  of  the  concepts  contained  in  these  notes  were  originally  developed  by  Grady  Booch 
(Rational,  Inc.),  and  will  be  amplified  in  his  soon  to  be  published  book  ( Software 
Components  With  Ada ,  Benjamin/Cummings).  Specifically,  the  terminology  associated 
with  reusable  modules  and  the  concept  of  subsystems  were  first  described  by  Mr.  Booch  in 
previous  tutorials.  While  there  is  no  formal  working  arrangement  between  Mr.  Booch  and 
EVB  Software  Engineering,  Inc.,  EVB  recognizes  and  appreciates  the  pioneering  work 
done  by  Mr.  Booch. 
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If  Hardware 
People  Thought 
Like  Software 
People 

•  “ There  are  some  unused  ‘op 
codes’  in  this  CPU  for  this 
specific  application.  Why  don’t 
we  remove  the  extra  ones?” 

•  “There  are  613  unused  bytes  of 
RAM  for  this  application.  Let's 
redesign  the  hardware  so  that 
we  can  remove  the  extra 
memory?” 

•  “Using  an  ‘off-the-shelf  CPU 
is  for  wimps.  Let’s  design  our 
own  application-specific  CPU 
for  this  application.  The  same 
goes  for  integrated  circuits  in 
general.” 
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Definitions 

•  MemmMUty :  the  extent  to 
which  a  module  can  be  used  in 
multiple  applications.  (This 
definition  skirts  the  issue  of 
how  much  change,  if  any, 
might  be  required  in  the 
module's  code.) 

•  P <n>HmMMty :  The  ease  with 
which  software  can  be 
transferred  from  one  computer 
system  or  environment  to 
another. 

•  MdD/MfmJbUUy :  The  ease  with 
which  a  piece  of  software  may 
be  changed  to  suit  a  specific 
application. 
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Definitions 

(Continued) 


•  MmmtmmmMIMy:  The  ease 
with  which  maintenance  of  a 
functional  unit  can  be 
performed  in  accordance  with 
prescribed  requirements. 

•  MeimMMtty:  The  probability 
that  software  will  not  cause  the 
failure  of  a  system  for  a 
specified  time  under  specified 
conditions. 

•  Afostmetwm:  A  view  of  a 
problem  that  extracts  the 
essential  information  relevant 
to  a  particular  purpose  and 
ignores  the  remainder  of  the 
information. 
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Definitions 

(Continued) 


•  F urns U cd maul  AlbsttrsKstlmm:  A 

view  of  a  problem  that  permits 
the  user  to  know  precisely 
about  the  input-output 
specification  while  hiding  the 
underlying  implementation  of 
the  function  itself.  ( This 
permits  reusability  of  the 
function  for  varying  data  of  a 
fixed  type.) 

•  EDmUai  Alb  stir  siusHmm:  A  view  of 
a  problem  that  hides  both  the 
underlying  structure  of  the 
input-output  data  and  the 
underlying  functionality  of  a 
module.The  user  may 
occasionally  know  some  of  the 
details  of  the  underlying 
algorithms  used  in  the  module. 
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Definitions 

(Continued) 


•  Pr<n><5<sss  AbsirmsttiuDm: 

Similar  to  data  abstraction,  but 
differs  in  having  an 
independent  executing  thread 
of  control  that  determines  the 
order  in  which  operations 
become  available  for  execution 
( includes  concurrent 
processes). 

•  UmMUty:  The  ease  with 
which  a  piece  of  software  may 
be  used  for  a  specific 
application. 
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Reusability 

Axioms 

•  Reusability  is  not  an  absolute 
(or  discrete )  concept. 

•  The  Ada  programming  language 
provides  reusability  concepts 
which  are  fundamentally 
different  from  those  in  most 
other  commonly  used 
programming  languages. 

•  Reusability  is  increased  when 
software  engineers  achieve  the 
goals  of  software  engineering 
by  adhering  to  the  principles  of 
software  engineering. 

•  Management  must  encourage 
the  reuse  of  software,  and 
software  engineers  must  both 
design  and  use  reusable 
software. 
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Reusability 

Axioms 

(Continued) 

•  Reusable  software  must  be 
promulgated  within  an 
organization. 

•  Reusability  must  be  defined, 
measured,  recorded,  and 
increased. 

•  Software  engineers  must  avoid 
language!  implementation 
tricks. 

•  Software  engineers  must  know 
what  factors  affect  reusability. 

•  Software  engineers  must  know 
what  factors  affect  portability. 

•  Reusability  and  portability  are 
enhanced  when  modules  are 
functionally  cohesive  and 
loosely  coupled,  i.e.,  they  are 
highly  independent. 
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Reusability 

Axioms 

(Continued) 

Reusability  and  portability  are 
enhanced  when  modules  have 
well-defined  interfaces. 

Software  engineers  must  know 
what  is  general  and  what  is 
specific  to  an  application. 

Robust  modules  ( created 
through  defensive 
programming)  are  more 
reusable  than  non-robust 
modules. 

Practice  conceptual  integrity. 

There  are  times  when 
reusability  is  not  important. 
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What  Can  Be 
Reused? 


•  Code  Fragments 

•  Modules  (components) 

•  Subsystems  (Rational/ Booch 
definition) 

•  Tools 

•  Designs 
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General  Ada 
Coding  Style 
Guidelines  for 

Ada  Reusability 

•  Use  meaningful  identifiers. 

•  Make  frequent  use  of 
attributes. 

•  Avoid  literal  constants. 

•  Use  named  parameter 
association. 

•  Avoid  the  “ use ”  clause. 

•  Use  the  “renames”  only  to 
expose  part  of  an  abstraction. 

•  Use  fully -qualified  names 

•  Create  adequate,  concise,  and 
precise  comments. 
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Style  Guidelines 

(Continued) 

•  Fully  exploit  the  separate 
compilation  features  of  the  Ada 
language . 

•  Make  frequent  use  of  subunits. 

•  Avoid  default  values  for 
descriminants,  record  field 
values,  and  formal  parameters. 

•  Avoid  pragmas. 

•  Avoid 

“unchecked_deallocation.” 

•  Avoid 

“uncheckedjconversion.” 

•  Avoid  anonymous  types. 

•  Avoid  pre-defined  and 
implementation-defined  types. 

•  Avoid  optional  language 
features. 
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Style  Guidelines 

(Continued) 


•  Avoid  attention  to  underlying 
implementations. 

•  Avoid  restrictive  modules. 

•  Strive  for  limited  private  types. 

•  Make  frequent  and  appropriate 
use  of  packages. 

•  Make  very  frequent  and 
appropriate  use  of  generics. 

•  Isolate,  and  clearly  identify 
en  vironmentally-dependent 
code. 

•  Watch  out  for  assumptions 
about  garbage  collection. 


<£1986  EVB  Software  Engineering,  inc. 


Reusable 

Modules 


Let  us  consider  the  implemention  of  a 
data  structure  in  the  Ada  language. 
For  purposes  of  example,  consider  a 
stack.  A  stmck  is  a  list  to  which  we 
may  add  or  delete  items  from  one  end 
only,  i.e.,  it  is  a  last-in-first-out  data 
structure.  The  question  is:  “ how  are 
we  to  implement  a  stack  in  the  Ada 
language?” 
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Reusable 

Modules 

(Continued) 

•  FORTRAN  Mindset: 

Implement  the  stack  as  an  array 

•  PmsmS/C  Mindset:  Implement 

the  stack  as  a  linked  list  q 

•  FnmUi'm  Adm  Mindset: 

Implement  the  stack  as  a 
package 

•  Ad/sqmMe  Adm  Mindset: 

Implement  the  stack  as  a 
generic  package 

I 

•  Advmmetgd  Adm  Mindset:  ! 

Implement  the  stack  as  a  family 

of  generic  packages.  \ 

I 

I 

m 
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Reusable 

Modules 

(Continued) 


The  experienced  software  engineer 
recognizes  that  the  tjni£jjpg£je 
behavior  of  a  component  is  as 
important  as  its  functional  behavior . 
(This  emphasis  on  functional 
behavior  is  often  the  result  of  a 
functional  decompostion  approach  to 
the  design  of  software .)  When  we 
speak  of  time  we  are 

concerned  with  the  behavior  of  the 
component  in  a  concurrent 
environment.  When  we  speak  of 
sjpmce  Mhmmm,  we  are  concerned 
with  how  a  component  utilizes 
memory. 
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Characteristics  of 
Highly-Reusable 
Operations 


•  FHmMwts:  The  operation 
cannot  be  implemented  without 
knowledge  of  the  underlying 
implementation  of  the  object 

•  CttmphUts:  We  have  a  minimal 
set  of  primitive  operations 
which  will  allow  us  to 
implement  all  necessary 
operations  for  the  object 

•  SmfficiemS:  We  have  added 
additional  operations  to  our 
minimal  set  of  operations  to 
enhance  the  usability  of  our 
abstraction. 
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Classification  of 
Objects 


•  MazmasUtMc:  The  object  is  not 
composed  of  substructures, 
e.g.,  stacks  and  queues 


• .  P (tDlylUhw :  The  object  may  be 
viewed  as  being  composed  of 
identical  substructures,  i.e., 
the  object  is  recursively 
defined,  e.g.,  lists  and  trees 
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Classification  of 
Operations 


•  SeUcttm:  Returns  information 
about  an  object ,  but  cannot 
change  the  state  of  the  object 

•  € dumstnsiw :  Changes  the 
state  of  an  object,  often  does 
not  return  information  about 
the  object 

•  For  objects  which 
have  a  structure,  allows  us  to 
visit  each  node  of  the  structure 
and  to  perform  some  operation 
at  each  node.  This  operation  is 
characteristically  a  selector 
operation. 
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Taxonomy  of 
Primitive 
Reusable 
Modules 


Bounded/Unbounded 

Iterator! Non-Iterator 

Managed/Unmanaged 

Concurrent!  Sequential! Guarded! 
Controlled!  Multiple 

Priority/Non-Priority 

Balking!  Non-Balking 

Limited! Non-Limited 
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Bounded  Vs 
Unbounded 


•  Mammdsd:  There  is  a  specified 
upper  limit  to  the  number  of 
nodes  in  the  data  structure, 
which  is  specified  at 
declaration  time.  (Note:  The 
underlying  implementation  is 
accomplished  via  sequential 
allocation,  and  the  use  of  gny 
dynamic  variables  is  strongly 
discouraged .) 

•  UmbaDumded:  The  data 
structure  is  free  to  grow  or 
shrink  based  on  available 
computer  resources.  These  are 
implemented  using  linked 
allocation. 
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iterator  Vs.  Non 

Iterator 


•  Mfsirmtm:  The  component 
provides  an  iterator  operation, 
i.e.,  a  means  of  visiting  all  the 
nodes  in  the  underlying 
abstraction  and  performing 
some  action  at  each  node. 

•  N a»m=‘lI(l<3F(8it@r :  The  component 
does  not  provide  an  iterator 
capability 


©1986  EVB  Software  Engineering,  Inc. 


Managed  Vs. 
Unmanaged 


•  MmmtBgtsd:  The  component 
provides  its  own  memory 
management,  e.g.,  it  maintains 
a  “free  list”  of  available  nodes 
rather  than  depending  on 
features  such  as 
uncheckedjdeallocation 

•  Ummmmmged:  the  component 
provides  no  memory 
management  capabilities,  i.e., 
it  depends  on  those  provided 
by  the  environment 
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Sequential, 

Concurrent, 

Guarded, 

Controlled, 

Multiple 

•  SsqmtemttmE:  The  component 
will  behave  as  expected  in  a 
non-concurrent  environment. 

In  a  concurrent  environment, 
the  component  mav  be  subject 
to  data  and  process  pollution. 

•  CdDmcurremi:  The  component 
will  behave  in  a  reasonable 
manner  in  a  concurrent 
environment,  i.e.,  the 
component  is  constructed  so  as 
to  avoid  data  and  process 
pollution.  No  user  action  is 
required 
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Sequential, 

Concurrent, 

Guarded, 

Controlled, 

Multiple 

(Continued) 

•  Gmmrded:  The  component 
provides  the  user  with  the 
capability  of  using  the 
component  in  a  concurrent 
environment,  i.e.,  a  semaphore 
mechanism  to  “lock”  and 
“ unlock ”  objects.  While  this  is 
very  dangerous  (as  opposed  to 
concurrent  components)  the 
user  has  the  ability  to  easily 
construct  higher-level 
operations  from  the  “atomic” 
operations  provided  in  the 
guarded  component. 
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Sequential, 

Concurrent, 

Guarded, 

Controlled, 

Multiple 

(Continued) 

The  user  of  the 
component  will  prevent  the 
object  from  being 
simultaneously  accessed  by 
two  or  more  processes.  The 
component ,  in  turn,  will 
protect  any  state  information 
(e.g.,  a  free  list)  contained 
within  the  component.  Note 
that  concurrent  components 
may  be  built  on  top  of 
controlled  components. 
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Sequential, 

Concurrent, 

Guarded, 

Controlled, 

Multiple 

(Continued) 

•  Multiple  :  The  component 
provides  for  multiple  reads 
(selector  operations)  of  an 
object  while  sequentializing 
writes  (constructor  operations ) 
to  the  object.  This  allows  for  a 
high  degree  of  concurrent 
access  to  an  object  while 
preventing  corruption  of  the 
object  or  state  information 
associated  with  the  object. 
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Priority  Vs.  Non- 

Priority 


•  Priority:  The  nodes  in  the 
data  structure  are  ordered 
based  on  a  priority  scheme, 
e.g.,  a  priority  queue.  (Note: 
In  a  priority  structure, 
operations  on  the  nodes  are 
dependent  on  both  those 
normally  associated  with  the 
abstraction,  and  on  the  priority 
of  the  items  placed  in  the 
structure .) 

•  The  items  in 
the  data  structure  are  not 
treated  on  any  priority  basis. 
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Balking  Vs.  Non- 

Balking 


•  MmUMmg:  Items  may  be 
removed  from  a  data  structure 
in  a  manner  other  than  that 
normally  associated  with  the 
abstraction,  e.g.,  in  a  balking 
queue,  items  may  be  removed 
without  first  bringing  them  to 
the  front  of  the  queue. 

•  N<n>m°IBmJlkmg:  The  component 
provides  no  other  operations 
for  the  removal  of  items  from  a 
data  structure  other  than  those 
normally  associated  with  the 
abstraction 
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Limited  Vs.  Non 

Limited 


Limited:  The  abstraction  is  a 
very  large  data  structure  with 
specific  bounds,  however,  the 
underlying  implementation  is 
accomplished  via  linked 
allocation,  e.g.,  sparse 
matrices 

Nm>m=LimU<sd:  The  underlying 
implementation  is  consistent 
with  the  abstraction,  i.e., 
bounded  components  are 
implemented  using  sequential 
allocation  and  unbounded 
components  are  implemented 
using  linked  allocation. 
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Concurrency 

Issues 


•  Data  and  process  pollution 

•  Indeterminacy 

•  Deadlocking  & 

•  Friendly  vs.  unfriendly  tasking 
implementations 

•  Degree  of  concurrency 

•  Guarded  vs.  Concurrent 
components 
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Garbage 

Collection  Issues 


•  Use  or  non-use  of  access  types 

•  Allocation  of  heap  storage, 
e.g.: 

for  Item ' Storage_Size  use 
5*Kilo_Bytes  ; 

•  Use  of 

“ unchecked_deallocation ” 

•  Time  to  allocate  and  deallocate 
heap  storage 
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Compiler  Issues 


Avoidance  of  compiler 
dependent  features 

Considering  compiler 
optimization  features 

Avoidance  of  “ tuning ”  the  Ada 
code  to  any  specific  compiler 
(or  hardware ) 
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Exceptions  In 
Reusable 
Components 


•  Use  of  exceptions  to  report 
exceptional  conditions 

•  Designing  and  exporting  well- 
named  exceptions 

•  Noting  the  use  of  exceptions  in 
the  comments  for  program 
units 

•  Handling  exceptions  in  Ada 
tasks 
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Efficiency  Issues 


Inverse  relationship  between 
efficiency  and  reliability 

Efficiency  vs.  reusability 

Efficiency  vs.  portability 

Use  of  pre-existing,  proven 
algorithms 

How  much  efficiency  should 
you  strive  for 

Exporting  objects  vs.  exporting 
types  ( this  is  also  a  strong 
usability  issue) 
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Subsystems 


SwlbsysitsiMS  are  collections  of 
packages  ( mostly  generic  packages) 
which  behave  logically  like  packages, 


i.e.: 


The  collection  is  treated  as  a 
unit  (even  though  the  syntax 
and  semantics  of  the  Ada 
language  may  not  necessarily 
be  used  to  enforce  this) 

Objects  and  types,  as  well  as 
operations  may  be  exported 

Some  of  the  operations, 
objects,  and  types  are  visible 
while  others  are  hidden 
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Subsystems 

(Continued) 

•  The  hardware  analog  of  a 
subsystem  is  a  populated 
printed  circuit  (pc)  board 

•  Subsystems  are  of  a  higher 
level  of  abstraction  than 
packages 

•  Like  populated  pc  boards, 
subsystems  are  not  stand-alone 
applications,  but  are  used  to 
construct  applications 

•  Examples  of  subsystems 
include  menu  subsystems  and 
windowing  subsystems 

•  Subsystems  are  less  common 
than  reusable  modules  and  tend 
to  be  more  vertical  than 
horizontal  in  their  application 
areas 
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Tools 


Tmh  are  stand-alone  applications. 
The  usual  connotation  is  that  they  are 
used  by  software  engineers  to 
automate  various  parts  of  the 
software  life-cycle.  Booch  classifies 
tools  as: 


•  Utilities 

•  Filters  ( Kernighan  and 
Plauger) 

•  Sorting 

•  Searching 
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Tools 

(Continued) 


Often  tools  are  considered  within  the 
context  of  a  software  engineering 
environment.  This  implies  that  their 
reusability  will  be  strongly  connected 
to  their  ability  to  interact  / integrate 
with  the  environment,  and  their 
ability  to  interact! integrate  with  other 
tools.  In  the  Ada  world,  this  requires 
some  additional  concepts: 


•  DIANA 

•  Discrete  tools  (e.g.,  tools  in  a 
UNIX™  or  VMS  environment) 

•  Diffuse  tools  (e.g.,  tools  in  the 
Rational  Environment) 
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Tools 

(Continued) 


Tools  may  be  either  stand-alone  or 
invokable  from  within  an  application. 
For  example ,  a  tool  which  analyzes 
the  complexity  of  Ada  source  code 
might  be  parameterized  so  that  it  may 
be  called  from  within  an  application 
and  pass  the  complexity  information 
to  the  calling  unit  as  an  abstraction. 
Note  that  this  increases  the 
reusability  of  the  tool. 
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Tools 


(Continued) 

To  increase  the  reusability  and 
portability  of  a  tool,  the  software 
engineer  should: 


Isolate  and  clearly  identify  any 

implementation-dependent 

modules 

Use  packages  instead  of  files 
for  I/O. 

Follow  the  previously 
mentioned  Ada  coding  style 
guidelines 

Not  attempt  to  tailor  the  tool 
for  any  specific  Ada 
implementation 
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Reusable  Designs 


•  With  all  due  respect  to  Ada  as  a 
DL,  we  will  define  a  software 
design  as  any  non-code 
software,  e.g.,  documentation. 

•  A  previously-existing  design 
for  a  non-Ada  implementation 
could  be  reused  to  implement 
the  application  in  the  Ada 
language. 

•  With  a  well-engineered  design 
(most  likely  not  produced  via  a 
functional  decomposition 
approach ),  parts  of  the  design 
might  be  incorporated  into 
(reused)  another  Ada 
application. 
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Designing  With 
Reusability  In 
Mind 

•  Two  basic  problems:  produce 
reusable  software  as  a  by¬ 
product  of  the  design  effort, 
and  to  make  use  of  previously 
existing  reusable  software. 

•  Some  software  development 
methodologies  are  more  prone 
than  others  to  produce  reusable 
software. 

•  Reusable  software  can  be  used 
in  both  a  top-down  and  a 
bottom-up  design  effort. 

•  Rapid  prototyping  is  possible 
with  carefully  constructed 
reusable  components. 
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Designing  With 
Reusability  In 
Mind 

(Continued) 


One  of  the  largest  impediments  to  the 
creation  and  use  of  reusable  software 
is  the  creation  of  a  hardware 
architecture  first ,  and  then  requiring 
that  the  software  be  designed  around 
the  hardware.  A  far  better  approach  is 
software  first,  i.e.,  the  software  is 
designed  first,  and  then  the  hardware 
is  designed  and  built  to  support  the 
software. 
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Major  Obstacles 
to  Reusable 
Software 

•  NIH 

•  “ Only  wimps  use  someone 
else's  software 

•  Contracting  procedures  which 
encourage  “ re-invention  of  the 
wheel,”  large  staffing,  and  low 
quality  software 

•  Lack  of  confidence  in  the 
quality  of  potentially  reusable 
software,  i.e.,  lack  of  a  formal 
certification  mechanism 

•  Lack  of  technical  expertise 

•  Unawareness  of  technology,  or 
reusable  components 

•  Lack  of  useful  tools 
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An  Example  of  Ada  Code 

1  Defining  the  Probiem 

1.1  Stating  the  Problem 

Create  a  generic  bounded  stack  package. 

1.2  Analysis  and  Clarifications  of  the  Givens 

1.  The  following  is  a  definition  of  a  linear  list  :  “A  linear  list  is  a  set  of  n  0 
nodes  X[l],  X[2], ....  X[n]  whose  structural  properties  essentially  involve  only  the 
linear  (one-dimensional)  relative  positions  of  the  nodes:  the  facts  that,  if  n  >  -  0  , 
X[l]  is  the  first  node;  when  /<£<«,  the  kth  node  X[k  ]  is  preceded  by  X[fc  -  1] 
and  followed  by  X[k  +  1];  and  X[/i  ]  is  the  last  node.”  (See  [Knuth,  1973].) 

2.  A  stack  is  defined  to  be  “a  linear  list  for  which  all  insertions  and  deletions  (and 
usually  all  accesses)  are  made  at  one  end  of  the  list”  ([Knuth,  1973]).  This  end  is 
usually  called  the  top  of  the  stack.  Notice  that  the  above  definition  implicitly  states 
the  Last-In-First-Out  (LIFO)  property  of  a  stack. 

3.  By  bounded,  we  mean  that  the  maximum  length  of  a  given  stack  does  not  change. 
Thus,  a  user  of  this  generic  must  specify  the  desired  length  of  a  stack  when  the 
stack  object  is  declared. 

4.  The  stack  abstraction  must  be  sufficient,  complete,  and  primitive.  Sufficient 
means  that  a  sufficient  variety  of  operations  are  provided  to  allow  the  user  of  the 
abstraction  to  implement  what  is  needed.  Complete  means  that  all  aspects  of  the 
abstract  behaviour  of  the  abstraction  are  captured.  Primitive  means  that  only  those 
operations  that  could  not  be  implemented  effectively  without  access  to  the 
underlying  implementation  are  provided. 

5.  The  following  operations  (meeting  the  tradeoffs  of  the  criteria  defined  above)  are 
defined  inside  the  stack  package:  push  down  an  element  onto  a  stack,  pop  up  an 
element  off  a  stack,  check  whether  a  stack  is  empty  or  full,  find  out  how  many 
elements  are  currently  in  a  given  stack,  find  out  the  top  element  in  the  stack,  peek  at 
the  n  *  element  below  the  top  (where  1  <-  n  <=  current  number  of  elements  in 
the  stack),  clear  a  given  stack  (i.e.,  create  an  empty  stack),  test  two  stacks  for 
equality,  and  copy  one  stack  to  another. 

6.  If  a  given  stack  is  empty  and  the  user  tries  to  pop  an  element  off  the  stack,  an 
exception  (Underflow)  will  be  raised. 

7.  Overflow  will  be  raised  if  a  user  tries  to  push  an  element  onto  a  full  stack. 

8.  Element  Not_Found  will  be  raised  if  a  user  tries  to  peek  at  a  non-existent 
element  or* tries  "to  find  out  the  top  element  in  an  empty  stack. 

9.  We  are  not  concerned  with  what  types  of  elements  are  put  on  the  stack.  As  many 
kinds  of  elements  as  possible  should  be  allowed. 


©1986  EVB  Software  Engineering,  Inc. 


2  Developing  an  Informal  Strategy 

A  user  will  be  able  to  push  an  element  onto  a  stack,  pop  an  element  off  a  stack,  find  out 
whether  a  stack  is  empty,  find  out  whether  a  stack  is  full,  determine  the  number  of 
elements  in  a  stack,  find  out  the  top  element  in  a  stack,  peek  at  an  element  in  a  stack,  and 
clear  a  stack.  The  user  will  also  be  provided  with  a  means  to  test  two  stacks  for  equality 
and  a  means  of  copying  the  contents  of  one  stack  to  another. 
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3  Formalizing  the  Strategy 

3.1  Identifying  the  Objects  of  Interest 

3.1.1  Identifying  Objects  and  Types 

A  user  will  be  able  to  push  an  element  onto  a  stack,  pop  an  element  off  a  stack,  find 
out  whether  a  stack  is  empty,  find  out  whether  a  stack  is  full,  determine  the  number  of 
elements  in  a  stack,  find  out  the  ton  element  in  a  stack,  peek  at  an  element  in  a 
stack,  and  clear  a  stack.The  user  will  also  be  provided  with  a  means  to  test  two  stacks 
for  equality  and  a  means  of  copying  the  contents  of  one  stack  to  another. 


Objects 

Space 

Identifier 

user 

Problem 

element 

Solution 

Element 

stack 

Solution 

Stack 

top  element 

Solution 

(^Element) 
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3.1.2  Associating  Attributes  with  the  Objects  and 
Types  of  Interest 


Element 

—  is  an  abstract  type 

—  can  be  copied 

—  can  be  tested  to  see  if  it  is  equal  to  another  element 

Stack 

—  defines  an  abstract  type 

—  its  fixed  maximum  length  does  not  change 

—  can  be  empty 

—  can  be  full 


—  can  contain  up  to  some  user-defined  maximum  number  of  items 

—  elements  in  a  stack  are  pushed  on  to  the  top  of  the  stack,  or  popped  from  the  top 
of  the  stack,  but  all  insertions  and  deletions  are  from  that  end  only. 

—  The  Last  element  In  is  the  First  element  Out  (LIFO) 
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3.2  Identifying  the  Operations  of  Interest 
3.2.1  Identifying  Operations 

A  user  will  hfc  able  to  push  an  element  onto  a  stack,  pod  an  element  off  a  stack,  find 
QUt  whether,  a  Stack  ia  .empty,  find  out  whether  a  stack  is  full,  determine  the 
number  of  elements  in  a  stack,  find  out  the  top  element  in  a  stack,  peek  at  an  element  in  a 
Stack  and  clear  a  stack.  The  user  will  also  be  provided  with  a  means  to  test  two 
stacks  for  equality  and  a  means  of  copying  the  contents  of  one  stack  to  another. 


Operations 

Space 

Objects 

Identifier 

will  be  able 

Problem 

push  an  element  onto  a  stack 

Solution 

Stack 

Push 

pop  an  element  off  a  stack 

Solution 

Stack 

Pop 

find  out  whether ...  is  empty 

Solution 

Stack 

Is_Empty 

find  out  whether ...  is  full 

Solution 

Stack 

Is_Full 

determine  number  of  elements 

Solution 

Stack 

Number_Of_Elements 

find  out  the  top  element  in  a  stack 

Solution 

Stack 

Top_Of 

peek  at  an  element  in  a  stek 

Solution 

Stack 

Peek 

clear  a  stack 

Solution 

Stack 

Clear 

will  also  be  provided 

Problem 

to  test  two  stacks  for  equality 

Solution 

Stack 

if  i« 

copying  the  contents  of  one  stack  to  another 

Solution 

Stack 

Copy 
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3.2.2  Associating  Attributes  with  the  Operations 
of  Interest 

Push 

—  Is  a  constructor 

~  puts  a  given  element  onto  the  top  of  a  given  stack 

—  raises  an  exception  (Overflow)  if  a  user  tries  to  push  an  element  onto  a  full 
stack 

Pop 

—  Is  a  constructor 

—  pops  the  top  element  off  a  given  stack 

—  raises  an  exception  (Underflow)  if  a  user  tries  to  pop  an  element  off  an 
empty  stack 

Is_Empty 

—  Is  a  selector 

—  has  a  true  value  if  the  given  stack  is  empty;  false  otherwise 

Is_Full 

—  Is  a  selector 

—  has  a  true  value  if  the  given  stack  is  full;  false  otherwise 
Numbcr_Of_Elements 

—  Is  a  selector 

—  is  the  current  number  of  elements  in  a  given  stack 

Top_Of 

—  Is  a  selector 

—  allows  a  user  to  look  at  the  content  of  the  top  of  a  given  stack,  i.e.,  the  top 
element  in  a  given  stack 

—  raises  an  exception  (Element_Not_Found)  if  the  stack  is  empty 

Peek 

—  Is  a  selector 
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—  allows  a  user  to  look  at  the  n*h  element  in  a  given  stack  (including  the  top) 

—  raises  an  exception  (Element_Not_F ound)  if  a  user  tries  to  peek  at  a 
non-existent  element  (e.g.,  there  are  currently  5  elements  in  a  stack  and  a 

user  tries  to  peek  at  the  8^  element) 

□ear 

—  Is  a  constructor 

—  initialize  stack  to  empty  stack 

t  M 

set 

—  Is  a  selector 

—  returns  true  if  two  stacks  are  equal 

—  two  stacks  are  equal  if  the  following  conditions  are  all  true : 

1 .  the  current  number  of  elements  in  both  stacks  are  equal,  and 

2.  the  values  of  the  corresponding  elements  in  both  stacks  are  equal 

-°py 

--  Is  a  constructor 

—  copy  one  entire  stack  to  another 

—  will  raise  an  exception  (Overflow)  if  the  destination  stack  has  an  upper 
bound  that  is  smaller  than  the  number  of  elements  in  the  source  stack 
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3.2.3  Grouping  Operations,  Objects,  and  Types 


Stack 


Push 


Elements 


Is_Empty 

Is_Full 

Number_Of_Elements 

Top_Of 


Gear 


Copy 


«none»  (is  part  of  the  interface  data  to  the  other  program  units.  See  [EVB, 
1985]  page  3-38  #  3.) 
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3.3  Defining  the  Interfaces 

3.3.1  Formal  Description  of  the  Visible  Interfaces 

The  generic  package  Bounded_Stack  contains: 

the  generic  formal  parameter  Element, 

the  type  Stack, 

and  the  following  operations: 

Push 

Pop 

Is  Empty 
Isjnill 

Number  Of  Elements 

Top_Of 

Peek 

Clear 

#*  i* 

Copy, 

and  the  following  exceptions: 

Underflow 

Overflow 

Elemcnt_Not_Found 
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3.3.2  Analysis  and  Clarifications  of  High-Level 
Design  Decisions 


The  generic  formal  type  parameter  Element  will  be  of  type  private  to  satisfy  the 
criteria  set  down  in  the  Analysis  and  Garifications  fo  the  Givens  (1.2)  number  9 
and  the  fact  that  assignment  of  Elements  will  be  needed  in  order  to  put  things  onto 
the  stack. 
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3.4  Implementing  the  Solution 

3.4.1  Implementing  the  Operation  Interfaces 

generic 

type  Element  is  private  ; 

—  Element  is  the  type  of  object  that  will  be  put  on  the  stack 
package  Bounded_Stack  is 


—  This  generic  bounded  stack  package  provides  stack  manipulation 

—  operations  neccessary  for  most  applications  where  stack  data 

—  structure  is  needed.  In  building  this  package,  we  were  striving 

—  for  the  following:  operations  provided  in  this  package  must 

—  be  primitive  and  complete  and  sufficient. 

—  A  primitive  operation  is  an  operation  which  can  NOT  be 

—  implemented  effectively  WITHOUT  knowing  the  underlying 

—  representation  of  a  particular  object  (in  this  case  our 

—  object  is  STACK) .  By  complete  we  mean  that  a  user  will  find 

—  that  the  following  operations  will  be  the  ONLY  operations 

—  needed  to  manipulate  a  bounded  stack  in  almost  any  application. 

—  Whenever  neccessary,  a  user  will  be  able  to  build  other 

—  operations  based  only  on  the  operations  provided  in  this  package. 

—  Written  by  Johan  Margono,  reviewed  by  (in  alphabetical  order) : 

—  B.D.  Balfour,  E.V.  Berard,  G.E.  Russell 

—  Author  Revision  Date  Reason 


9  Jul  1985 

19  Mar  1986  "type  Stack  (Length  :  ..."  is 
changed  to  "type  Stack 
(Maximum_Length  :  ..."  to  be 
consistent  with  our  naming 
convention 

—  (c)  1986  EVB  Software  Engineering,  Inc. 


—  J.  Margono  1.0 

—  J.  Margono  2.0 


type  Stack  (Maximura_Length  :  Positive)  ia  limited  private 

procedure  Push  (This_Element  :  in  Element  ; 

Into_This_Stack  :  in  out  Stack)  ; 

push  This_Element  onto  the  top  of  Into_This_Stack; 

—  exception  Overflow  will  be  raised  if  Into_This_Stack  is  full 
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procedure  Pop  (Top_Element  out  Element  ; 

Off_This_Stack  :  in  out  Stack)  ; 

—  pop  Top_Element  off  Of f_This_Stack; 

—  exception  Underflow  will  be  raised  if  Of f_This_Stack  is  empty 

function  Ia_Empty  (This_Stack  :  in  Stack)  return  Boolean  ; 

—  returns  true  if  Thia_Stack  ia  Eepty;  false  otherwise 

function  Is_Full  (This_Stack  :  in  Stack)  return  Boolean  ; 

—  returns  true  if  This_Stack  is  full;  false  otherwise 

function  Number_Of_Elements  (In_This_Stack  :  in  Stack)  return  Natural 

—  returns  the  current  number  of  elements  in  In_This_Stack; 

—  eero  is  returned  if  In_This__Stack  is  empty 

function  Top_Of  (This_Stack  ;  in  Stack)  return  Element  ; 

—  returns  the  top  element  in  This_Stack; 

—  exception  Element_Not_Found  is  raised  if  This_Stack  is  empty 

function  Peek  (At_Element  :  in  Natural  ; 

In_This_Stack  :  in  Stack)  return  Element  ; 

—  returns  the  nth  element  in  In_This_Stack  1  <-  n  <■  length 

~  (n  is  equal  to  At_Element) .  If  At_Element  is  greater  than  the 
--  current  number  of  elements  in  In_This_Stack,  the  exception 

—  Element_Not_Found  will  be  raised  (note  :  Element_Not_Found  will 

—  also  be  raised  if  In_This_Stack  is  empty) 

procedure  Clear  (This_Stack  :  in  out  Stack)  ; 

—  makes  This_Stack  an  empty  stack 


function  (Left 


in  Stack  ;  Right  :  in  Stack)  return  Boolean 


—  returns  true  if  : 

—  1.  number  of  elements  in  Left  is  equal  to  number  of  elements 

—  in  Right,  AND 

—  2.  values  of  elements  in  Left  is  equal  to  values  of  elements 

—  in  Right  (i.e.,  in  corresponding  slots); 

—  false  otherwise 
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procedure  Copy  (This_Stack  :  in  Stack  ; 

Into  :  out  Stack)  ; 

—  copy  the  contents  of  one  stack  into  another  stack  (Into) ; 

—  will  raise  Overflow  if  the  destination  stack  (Into)  has 

—  length  that  is  smaller  than  the  number  of  elements  in  the 

—  source  stack  (This  Stack) 


Underflow  :  exception  ; 

—  raised  if  a  user  tries  to  pop  an  element  off  an  empty  stack 


Overflow  :  exception  ; 

~~  raised  if  a  user  tries  to  push  an  element  onto  a  full  stack 


Element_Not_Found  :  exception  ; 

—  raised  if  a  user  tries  to  find  the  top  of  an  empty  stack 

—  or  Peek  at  an  empty  stack  or  peek  at  non-existent  element 
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Erapty_Stack_Index  :  constant  0  ; 

type  Contents_Of_Stack  is  array  (Positive  range  <>)  of  Element 

type  Stack  (Maximum_Length  :  Positive)  is  record 
Top  :  Natural  Empty_Stack_Index  ; 

Contents  :  Contents_Of_Stack  (1  . .  Maximum_Length)  ; 

end  record  ; 

—  Stack  is  initially  Empty  (i.e..  Top  -  Empty_Stack_Index) 
end  Bounded  Stack  ; 
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3.4.2  Stepwise  Refinement  of  the  Highest-Level 
Program  Unit 

package  body  Bounded_Stack  is 


—  This  generic  bounded  stack  package  provides  stack  manipulation 

—  operations  neccessary  for  most  applications  where  stack  data 

—  structure  is  needed.  In  building  this  package,  we  were  striving 

—  for  the  following:  operations  provided  in  this  package  must 

—  be  primitive  and  complete  and  sufficient. 

—  A  primitive  operation  is  an  operation  which  can  NOT  be 

—  implemented  effectively  WITHOUT  knowing  the  underlying 

—  representation  of  a  particular  object  (in  this  case  our 

—  object  is  STACK) .  By  complete  we  mean  that  a  user  will  find 

—  that  the  following  operations  will  be  the  ONLY  operations 

—  needed  to  manipulate  a  bounded  stack  in  almost  any  application. 

--  Whenever  neccessary,  a  user  will  be  able  to  build  other 

—  operations  based  only  on  the  operations  provided  in  this  package . 

—  Written  by  Johan  Margono,  reviewed  by  (in  alphabetical  order) : 

—  B.D.  Balfour,  E.V.  Berard,  G.E.  Russell 

—  Author  Revision  Date  Reason 


— -  J.  Margono  1.0  8  Jul  1985 

~  (c)  1986  EVB  Software  Engineering,  Inc. 


procedure  Push  (This_Element  :  in  Element  ; 

Into_This_Staek  :  in  out  Stack)  is  separate  ; 

—  push  This_Element  onto  the  top  of  Into_This_Stack; 

—  exception  Overflow  will  be  raised  if  Into_This_Stack  is  full 


procedure  Pop  (Top_Element  :  out  Element  ; 

Of f_This_Stack  :  in  out  Stack)  is  separate  ; 

—  pop  Top_Element  off  Of f_This_Stack; 

—  exception  Underflow  will  be  raised  if  Of f__This_Stack  is  empty 


function  Is_Empty  (This_Stack  :  in  Stack)  return  Boolean  is  separata  ; 

—  returns  true  if  Th;s_Stack  is  empty;  false  otherwise 

function  Is_Full  (This_Stack  :  in  Stack)  return  Boolean  is  separate  ; 

—  returns  true  if  This  Stack  is  full;  false  otherwise 
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function  Number_Of_Elements  (In_This_Stack  :  in  Stack) 
ratuza  Natural  is  separata  ; 

—  returns  the  current  number  of  elements  in  In_This_Stack; 

—  zero  is  returned  if  In_This_Stack  is  empty 


function  Top_Of  (This_Stack  :  in  Stack)  raturn  Element  is  separate  ; 

—  returns  the  top  element  in  This_Stack; 

—  exception  Element_Not_Found  is  raised  if  This_Stack  is  empty 


function  Peek  (At_Element  :  in  Natural  ; 

In_This_Stack  :  in  Stack)  return  Element  is  separate; 

—  returns  the  nth  element  below  the  top  element  in  In_This_Stack 

—  (n  is  equal  to  At_Element) .  If  At_Element  is  greater  than  the 

—  current  number  of  elements  in  In_This_Stack  minus  one,  exception 

—  Element_Not_Found  will  be  raised  (note  :  Element_Not_Found  will 

—  also  be  raised  if  In__This_Stack  is  empty) 


procedure  Clear  (This_Stack  :  in  out  Stack)  is  separata  ; 
—  get  This_Stack  to  be  the  same  as  an  empty  stack 
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I 

function  "  (Left  :  in  Stack  ;  Right  :  in  Stack)  retuzn  Boolean  is 


—  returns  true  if  : 

—  1.  number  of  elements  in  Left  is  equal  to  number  of  elements 

—  in  Right,  AND 

—  2.  values  of  elements  in  Left  is  equal  to  values  of  elements 

■—  in  Right  (i.e.,  in  corresponding  slots); 

—  false  otherwise 


—  NOTE:  This  function  is  included  in  the  body  of  the  package  (as 

—  opposed  to  being  implemented  as  a  subunit)  because, 

—  according  to  section  10.1,  paragraph  3  of  the  Ada 

—  Language  Reference  Manual,  "The  designator  of  a 

—  separately  compiled  subprogram  (whether  a  library  unit 

—  or  a  subunit)  must  be  an  identifier." 


—  Written  by  Johan  Margono,  reviewed  by  (in  alphabetical  order) : 

—  B.D.  Balfour,  E.V.  Berard,  G.E.  Russell 


—  Author 


Revision 


Date 


Reason 


—  J.  Margono  1.0 

—  B.  Balfour  2.0 


8  Jul  1985 

20  Feb  1986  removed  restriction  that 
stacks  must  have  same 
length  (bounds) 


—  <c)  1986  EVB  Software  Engineering,  Inc. 


begin  —  "■" 

return  Left .Contents (1  ..  Left. Top)  •  Right .Contents (1  ..  Right. Top)  ; 

end  "”"  ; 
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procedure  Copy  (This_Stack 
Into 


Stack  ; 

out  Stack)  is  separate; 


—  copy  the  contents  of  This_Stack  into  another  stack  (Into) ; 

—  will  raise  Overflow  if  the  destination  stack  (Into)  has 

—  length  that  is  smaller  than  the  number  of  elements  in  the 

—  source  stack  (This  Stack) 


end  Bounded  Stack  ; 
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separata  (Bounded_Stack) 

procedure  Push  (This__Element  :  in  Element  ; 

Into  This  Stack  :  in  out  Stack)  is 


—  push  This_Element  onto  the  top  of  Into_This_Stack; 

—  exception  Overflow  will  be  raised  if  Into_This_Stack  is  full 

--  Written  by  Johan  Margono,  reviewed  by  (in  alphabetical  order) : 

—  B.D .  Balfour,  E.V.  Berard,  G.E.  Russell 


Author  Revision  Date 

J.  Margono  1.0  8  Jul  1985 

(c)  1986  EVB  Software  Engineering,  Inc. 


Reason 


begin  —  Push 

i t  Into_This_Stack.Tcp  -  Into__This_Stack .Maximum_Length  then 
raise  Overflow  ; 


else 


Into_This_Stack . Top  :«  Into_This_Stack . Top  +  1  ; 
Into_This__Stack.  Contents (Into_This_Stack.Top)  This_Element  ; 

end  if  ; 

end  Push  ; 
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separata  (Bounded_Stack) 

proceduse  Pop  (Top_Element  out  Element  ; 

Off  This  Stack  :  in  out  Stack)  is 


■—  pop  Top_Element  off  Off_This_Stack; 

—  exception  Underflow  will  be  raised  if  Of f_This_Stack  is  empty 

—  Written  by  Johan  Margono,  reviewed  by  (in  alphabetical  order) : 

—  B-.D.  Balfour,  E.V.  Berard,  G.E.  Russell 


Author 


Revision 


Reason 


J.  Margono  1.0 


8  Jul  1985 


(c)  1986  EVB  Software  Engineering,  Inc. 


bagin  —  Pop 

if  Off_This_Stack.Top  ”  Empty_Stack_Index  then 


rmisa  Underflow  ; 


alsa 

Top_Element  :*  Top_0f  (This_Stack  •>  Off_This_Stack) 
Of f_This_Stack . Top” : -  Of f_This_Stack . Top  -  1  ; 

and  if  ; 


m 


and  Pop 
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separate  (Bounded_Stack) 

function  Is_Empty  (This_Stack  :  in  Stack)  return  Boolean  ia 


—  returns  true  if  This_Stack  is  empty;  false  otherwise 


—  Written  by  Johan  Margono,  reviewed  by  (in  alphabetical  order) 

—  B.D.  Balfour,  E.V.  Berard,  G.E.  Russell 


—  Author 


Revision 


Reason 


J.  Margono  1.0 


8  Jul  1985 


--  (c)  1986  EVB  Software  Engineering,  Inc. 


begin  —  Is_Empty 


return  This_Stack .  Top  ■  Empty__Stack_Index 


end  Is_Empty  ; 
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separata  (Bounded_Stack) 

function  Is_Full  (This_Stac)c  :  in  Stack)  return  Boolean  is 


—  returns  true  if  This_Stack  is  full;  false  otherwise 


—  Written  by  Johan  Margono,  reviewed  by  (in  alphabetical  order) 

—  B.D.  Balfour,  E.V.  Berard,  G.E.  Russell 


—  Author 


Revision 


Reason 


J.  Margono  1.0 


8  Jul  1985 


—  (c)  1986  EVB  Software  Engineering,  Inc. 


begin  —  Is_Full 


—  check  if  top  of  stack  is  equal  to  length  of  stack 
return  This_Stack . Top  -  This_Stack.Maximuxn_Length  ; 


end  Is  Full  ; 
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sap* rat*  (Bounded_Stack) 

function  Number_Of_Elementa  (In_Thia_Stack  :  in  Stack)  r*turn  Natural  ia 


—  retuma  the  current  number  of  elementa  in  In_Thia_Stack; 

—  zero  ia  returned  if  In_Thia_ Stack  ia  empty  ~ 

—  Written  by  Johan  Margono,  reviewed  by  (in  alphabetical  order) 

—  B.D.  Balfour,  E.V.  Berard,  G.E.  Ruaaell 


—  Author 


Reviaion 


Reaaon 


J.  Margono  1.0 


8  Jul  1985 


—  (c)  1986  EVB  Software  Engineering,  Inc. 


begin  —  Number_Of_Elementa 
retun  In_Thia_Stack.Top  ; 
end  Number  Of  Elementa  ; 
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separate  (Bounded_Stack) 

function  Top_Of  (This_Stack  :  in  Stack)  raturn  Element  ia 


—  returns  the  top  element  in  This_Stack; 

—  exception  Element_Not_Found  is  raised  if  This_Stack  is  empty 

—  Written  by  Johan  Margono,  reviewed  by  (in  alphabetical  order) : 

—  B.D.  Balfour,  E.V.  Berard,  G.E.  Russell 


—  Author 


Revision  Date 


Reason 


—  J. 

—  J. 


Margono 

Margono 


1.0 

2.0 


8  Jul  1985 
19  Mar  1985 


Constraint_Error  will  not 
be  raised  if  pragma  SUPPRESS 
is  used 


—  (c)  1986  EVB  Software  Engineering,  Inc. 


begin  —  Top_Of 

if  This_Stack . Top  “  Empty_Stack_Index  then 
raise  Element_Not_Found  ; 

else 

return  This_Stack. Contents (This_Stack. Top)  ; 

end  if  ; 
end  Top_Of  ; 
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separata  (Bounded_Stack) 

function  Peek  (At_Element  :  in  Natural  ; 

In  This  Stack  :  in  Stack)  return  Element  is 


returns  the  nth  element  below  the  top  element  in  In_This_Stack 
(n  is  equal  to  At_Eleraent) .  If  At_Element  is  greater  than  the 
current  number  of  elements  in  In_This_Stack,  exception 
Element_Not_F.ound  will  be  raised  (note  :  Element_Not_Found  will 
also  be  raised  if  In_This_Stack  is  empty) 


Written  by  Johan  Margono,  reviewed  by  (in  alphabetical  order) : 
B.D.  Balfour,  E.V.  Berard,  G.E.  Russell 


—  Author 


Revision  Date 


Reason 


J.  Margono  1.0 
J.  Margono  2.0 


8  Jul  1985 
19  Mar  1985 


Constraint_Error  will  not 
be  raised  if  pragma  SUPPRESS 
is  used 


—  (c)  1986  EVB  Software  Engineering,  Inc. 


begin  —  Peek 


if  At_Element  >  In_This_Stack.Top  then 


raise  Element  Not  Found  ; 


else 


return  In_This_Stack. Contents (In_This_Stack.Top  -  At_Element  +  1) 


end  if  ; 


end  Peek  ; 


©1986  EVP  Software  Engineering,  Inc. 


.VwV.VvVwV*,' 


w 


separata  (Bounded_Stack) 

procedure  Clear  (This_Stack  :  in  out  Stack)  is 


—  set  This_Stack  to  be  an  empty  stack 

—  this  is  the  same  as  if  all  elements  had  been  popped  off. 


—  Written  by  Johan  Margono,  reviewed  by  (in  alphabetical  order) 

—  B.D.  Balfour,  E.V.  Berard,  G.E.  Russell 


—  Author 


Revision 


Reason 


—  J.  Margono 


8  Jul  1985 


—  (c)  1986  EVB  Software  Engineering,  Inc. 


begin  —  Clear 


—  re-assign  stack  top 
This_Stack.Top  Empty_Stack_Index  ; 


and  Clear  ; 
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separate  (Bounded_Stack) 

procedure  Copy  (This_Stack  :  in  Stack  ; 

Into  :  out  Stack)  is 


—  copy  the  contents  of  This_Stack  into  Into; 

—  will  raise  Overflow  if  the  destination  stack  (Into)  has 

—  length  that  is  smaller  than  the  number  of  elements  in  the 

—  source  stack  (This_Stack) 

—  Written  by  Johan  Margono,  reviewed  by  (in  alphabetical  order) : 

—  B.D.  Balfour,  E.V.  Berard,  G.E.  Russell 

—  Author  Revision  Date  Reason 


—  J.  Margono  1.0  8  Jul  1985 

—  (c)  1986  EVB  Software  Engineering,  Inc. 


begin  —  Copy 

if  This_Stack.Top  >  Into . Maximum_Length  than 
raise  Overflow; 

else  —  there  is  enough  room  to  put  the  contents  of 
—  This_Stack  into  Into 

Into. Top  :«  This_Stack.Top; 

Into. Contents (1  ..  This_Stack.Top) 

This_Stack .Contents (1  ..  This_Stack.Top) ; 

and  if; 

and  Copy  ; 
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3.4.3  Stepwise  Refinement  of  the  Other  Program 
Units 


None  required. 
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Test  Programs 


with  Text_IO  ; 
with  Bounded_Stack  ; 

procedure  Bounded_Stack_First_Teat  ia 


—  This  procedure  ia  a  driver  to  teat  the  bounded  atack  package. 

~  It  allowa  all  operationa  to  be  invoked  in  any  order. 

—  Written  by  J.  Margono,  and  reviewed  by  B.  D.  Balfour,  E.  V.  Berard, 

—  and  G.  E.  Ruaaell. 


—  Author 

Revision  Date 

Reason 

—  J .  Margono 

—  J.  Margono 

1.0 

2.0 

8  Jul 
20  Feb 

1985 

1986 

to  make  it  uniform  with 
all  other  first  testa 

—  (c)  1986  EVB 

Software 

Engineering, 

Inc . 

type  Command  ia 
(  Clear,  — 

Copy, 

Empty,  — 

Equal,  — 

Elements,  — 
Peek, 

Pop,  — 

Push, 

Top, 

View, 


a  atack 

a  atack  to  another  atack 
ia  a  atack  empty? 
are  two  atacka  equal? 
in  a  atack 

at  an  element  in  a  atack 
an  element  off  a  atack 
an  element  into  a  atack 
top  element  of  a  atack 
a  atack 


—  command  on  the  teat  program 
Quit  —  quit  the  test 

)  ; 


package  Command_IO  ia  new  Text_IO.Enumeration_IO (Enum  ->  Command); 

package  Integer_IO  ia  new  Text_IO . Integer_IO (Num  “>  Integer)  ; 
package  Bounded  is  new  Bounded_Stack (Element  ->  Integer)  ; 

—  Integer  ia  chosen  simply  to  represent  an  enumeration  data  type 


function  (Left  :  in  Bounded. Stack  ; 

Right  :  in  Bounded. Stack)  return  Boolean 
renames  Bounded."*"  ;  —  makes  "»"  directly  visible 

type  Acceaa_To_Stacka  is  access  Bounded. Stack  ; 

type  Array_Of_Stacka  is  array  (Positive  range  <>)  of  Accesa_To_Stacks 
Number_Of_Stacks  :  Positive  ; 

procedure  Display  (Thia_Stack  in  Bounded. Stack)  is  separate  ; 
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—  displays  the  contents  of  a  given  stack 


begin  —  Bounded_Stack_First_Test 

Get_Number_Of_Stacks : 
loop 

begin 

Text_IO.Put ("How  many  STACK (s)  do  you  need?  ")  ; 

Integer_IO. Get (Item  ->  Number_Of_Stacks)  ; 

exit  Get_Number_Of_Stacks  ;  —  when  there  is  no  error 

exception 

when  Text_IO.Data_Error  -> 

Text_IO.Skip_Line  ; 

Text__IO .Put_Line ("Enter  a  POSITIVE  number  only!!!")  ; 
when  Const raint_Error  -> 

Text_IO.PutJLine ("Enter  a  POSITIVE  number  only!!!")  ; 

when  other*  »> 

Text_IO . Put_Line ( "Unknown  exception  raised.  Re-enter.") 


end  ; 


end  loop  Get_Number_Of_Stacks  ; 
declare 


Stacks 


Array_Of__Stacks  (1  ..  Number_Of_Stacks) 


subtype  Stack_Range  is  Natural  range  1 


Number  Of  Stacks 


Stack_Index 
Stack  Size 


Stack_Range  : -  1 
Positive  ; 


User_Command 
User_Element 
Stack__Number 
Second_Stack_N\unber 
Element  Index 


Command  ; 
Integer  ; 
Positive  ; 
Positive  ; 
Positive  ; 


used  in  Copy  and  "*■" 
used  in  Peek 


begin 


Get_Stack_Sizes : 
loop 


begin 


Text_IO. Put ("Enter  size  for  stack  #")  ; 
Integer_IO. Put (Item  ->  Stack_Indexf  Width  «>  0)  ; 
Text_IO.Put ("  :  ")  ; 

Integer_IO. Get (Item  ->  Stack_Size)  ; 

—  declare  the  actual  stack 
Stacks (Stack  Index) 
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new  Bounded. Stack (Maximum_Length  ->  Stack_Size)  ; 
exit  Get_Stack_Sizea  when  Stack_Index  “  Number_Of_S tacks 
Stack_Index  Stack_Index  +  1  ; 

exception 

when  Text_IO.Data_Error  -> 

Text_IO.Skip_Line  ; 

Text~IO.Put_Line ("Enter  a  POSITIVE  number  only!!!")  ; 
when  Conatraint_Error  -> 

Text_IO.Put_Line ("Enter  a  POSITIVE  number  only!!!")  ; 

when  others  -> 

Text_IO.Put_Line ("Unknown  exception  raised.  Re-enter.") 

end  ; 

end  loop  Get_Stack_Sizea  ; 

Teat_Stack  : 
loop 

begin 

Text__IO.Put_.Line  ("Selections  :")  ; 

Text~IO . Put_Line ( "  STACK")  ; 

Text_IO.Put“l*in®("  Clear,  Copy,  Empty,  Equal*")  ; 

Text_ IO.Put__Line ("  Elements,  Peek,  Pop,  Push,")  ; 

Text_IO.Put  Line<"  Top,  '  View")  ; 

Text_IO.Put~Line<"  TEST_PROGRAM")  ; 

Text__IO . Put_Line  ( "  Quit")  ; 

Text_IO. Put ("Enter  selection  :  ")  ; 

Command_IO. Get (Item  ->  User_Command)  ; 

exit  Test_Stack  when  User_Command  -  Quit  ; 

case  User_Coznmand  is 

when  Push  -> 

Text__IO. Put  ("element  :  ")  ; 

Integer_IO. Get (Item  ->  User_Element)  ; 

Text_IO. Put ("stack  (1-")  ; 

Integer_IO. Put (Item  •>  Number_Of_Stacks,  Width  ->  0) 
Text_IO.Put (")  :  ")  ; 

Integer_IO. Get (Item  »>  Stack_Number)  ; 

Bounded. Push 

(This_Element  ->  User_Element, 

Into_This^Stack  ->  Stacks (Stack_Number) .all)  ; 

when  Pop  ■> 

Text_IO. Put ("stack  (1-")  ; 

Integer_IO. Put (Item  ->  Number_Of_Stacks,  Width  ->  0) 
Text_IO .Put (")  :  ")  ; 

Integer_IO. Get (Item  ■>  Stack_Number)  ; 
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Bounded. Pop <Top_Element  ->  User_Element, 

Off_This_Stack  ->  Stacks  (Stack_Number)  .all)  ; 
Text_IO.Put ("Top  element  was  ")  ; 

Integer_IO. Put  (Item  ->  User__Element,  Width  «>  0)  ; 
Text_IO.New_Line  ; 

when  Empty  -> 

Text_IO. Put ("stack  (1-")  ; 

Integer  10. Put  (Item  ■•>  Number_Of_Stacks,  Width  ->0)  ; 
Text_IO?Put<")  :  ; 

Integer_IO. Get (Item  ■>  Stack_Number)  ; 

if  Bounded. Is_Empty 

(This_Stack  *>  Stacks  (Stack_Number)  .all)  then 
Text_I0 . Put_Line ( "That  stack  is  empty.")  ; 

else 

Text  10. Put  Line ("That  stack  is  NOT  empty.")  ; 

end  if”; 

when  Elements  «> 

Text_I0. Put ("stack  (1-")  ; 

Integer_IO. Put (Item  ->  Number_Of_Stacks,  Width  ->  0)  ; 
Text_IO.Put (")  ;  ")  ; 

Integer_IO. Get (Item  ■>  Stack_Number)  ; 

Text_I0. Put ("Number  of  elements  in  that  stack  is  ")  ; 
Integer_IO . Put 

(Item  »>  Bounded. Number_Of_Elements 

(In_This  Stack  ->  Stacks (Stack_Number) .all) , 
Width  ->  0)  ; 

Text_IO .  Ne w_Line  ; 

when  Top  -> 

Text__IO. Put  ("stack  (1-")  ; 

Integer__IO. Put  (Item  «>  Number_Of_Stacks,  Width  ■>  0)  ; 
Text_I0 . Put  < " )  :  " )  ; 

Integer_IO. Get (Item  ■>  Stack_Number)  ; 

Text_IO.Put ("Top  element  is  ")  ; 

Integer_IO . Put 

(Item  ■>  Bounded. Top_0f 

(This_Stack  ->  Stacks (Stack_Number) .all) , 
Width  ->  0)  ; 

Text_IO . New_Line  ; 

when  Peek  -> 

Text__I0. Put  ("stack  (1-")  ; 

Integer_IO. Put (Item  ■>  Number_Of_Stacks,  Width  ■>  0)  ; 
Text_IO.Put<")  :  ")  ; 

Integer_IO. Get (Item  ->  Stack_Number)  ; 

Text_I0. Put ("Number  of  elements  in  that  stack  is  ")  ; 
Integer_IO . Put 

(Item  _>  Bounded. Number_Of_Elements 

(In_This  Stack  ->  Stacks (Stack  Number) .all) , 
Width  ->  0)  ; 

Text  10. New  Line  ; 
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Text_IO. Put ("which  element?  ")  ; 

Integer__IO. Get  (Item  «>  Element_Index)  ; 

Text_IO . Put ( "Peeked  element  is  ")  ; 

Integer_IO . Put 

(Item  «>  Bounded. Peek 

(At_Element  ■>  Element_Index, 

In_This  Stack  ->  Stacks (Stack  Number) .all) 
Width  0)  ; 

Text_I0 .  New_Line  ;• 

when  Equal  -> 

Text_IO. Put ("first  stack  (1-")  ; 

Integer_IO. Put (Item  •>  Number_Of_Stacks,  Width  ■>  0)  ; 
Text_IO.Put (")  :  ")  ; 

Integer_IO. Get (Item  ->  Stack_Number)  ; 

Text_IO. Put ("second  stack  (1-")  ; 

Integer_IO. Put (Item  ->  Number_Of_Stacks,  Width  ->  0)  ; 
Text_IO . Put ( " ) 

Integer_IO .Get (Item  ■>  Second_Stack_Number)  ; 

if  Stacks (Stack_Number) .all  - 

Stacks (Sec ond_Stack_Number) .all  then 
Text_IO.Put_Line ("Those  stacks  are  equal.")  ; 

•lae 

Text_IO . Put_Line ("Those  stacks  are  NOT  equal.")  ; 

end  if  ; 

when  Clear  -> 

Text_IO. Put ("stack  (1-")  ; 

Integer  10. Put (Item  ->  Number  Of_Stacks,  Width  «>  0)  ; 
Text_IO . Put ( " )  :  ")  ; 

Integer_IO. Get (Item  ->  Stack_Number)  ; 

Bounded. Clear (This_Stack  ->  Stacks (Stack_Number) .all)  ; 

when  Copy  -> 

Text_IO. Put ("source  stack  (1-")  ; 

Integer  IO. Put (Item  «>  Number_Of_Stacks,  Width  ->  0)  ; 
Text_Io7Put  (")  :  ")  ; 

Integer_IO. Get (Item  ■>  Stack_Number)  ; 

Text_IO. Put ("destination  stack  (1-")  ; 

Integer  IO. Put (Item  ■>  Number_Of_stacks,  Width  ■>  0)  ; 
Text_I07put (")  :"); 

Integer_IO. Get (Item  ■>  Second_Stack_Number)  ; 

Bounded . Copy 

(This_Stack  ->  Stacks (Stack_Number) . all, 

Into  ->  Stacks (Second^Stack_Number) .all)  ; 

when  view  •> 

Text_I0. Put ("stack  (1-")  / 

Integer_IO. Put (Item  ■>  Number  Of  Stacks,  Width  ->  0)  ; 
Text_IO.Put (")  :"); 

Integer_IO. Get (Item  ■>  Stack_Number)  ; 
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Display (This_Stack  ->  Stacks (Stack_Number) .all)  ; 
whan  others  -> 

Text_10. Put ("This  command  :  ")  ; 

Command_IO. Put (Item  •>  User_Command)  ; 

Text_IO . Put_Line ( "  is  not  implemented. ")  ; 

end  case  ; 

exception 

when  Bounded. Overflow  ■> 

Text_IO.Put_Line ("OVERFLOW  was  raised.")  ; 

when  Bounded. Element_Not_Found  •*> 

Text_IO.Put_Line("ELEMENT_NOT_FOUND  was  raised.")  ; 

when  Bounded. Underflow  ■> 

Text_IO.Put_Line ("UNDERFLOW  was  raised.")  ; 

when  Text_IO.Data_Error  -> 

Text_IO.Put_Line ("Incorrect  command.  Reenter.")  ; 

when  others  -> 

Text_IO . Put_Line ( "Unknown  exception  raised.  Reenter.")  ; 

end  ; 

end  loop  Test_Stack  ; 
end  ; 

exception 

when  others  ■> 

Text_IO . Put_Line ( "Unknown  exception  reached  the  main  program.")  ; 
Text_IO.Put_Line ("PROGRAM  EXECUTION  IS  TERMINATED.")  ; 

end  Bounded  Stack  First  Test  ; 
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ft 


separate  (Bounded_Stack_First_Test ) 

procedure  Display  (This_Stack  :  in  Bounded. Stack)  is 


—  displays  the  contents  of  a  given  stack 

—  Written  by  J.  Margono,  and  reviewed  by  B.  D.  Balfour,  E.  V.  Berard, 

—  and  G.  E.  Russell. 

—  Author  Revision  Date  Reason 

—  J.  Margono  1.0  22  Jan  1986 

—  (c)  1986  EVB  Software  Engineering,  Inc. 


begin  —  Display 

Text_IO . Put_Line ("Stack  contents  :")  ; 

Display_Elements : 

for  Index  in  1  . .  Bounded. 

Number_Of_Elements 
(In_This_Stack  ->  This_Stack)  loop 

Integer_IO. Put  (Item  «■>  Bounded. 

Peek  (At_Element  ••>  Index, 

In  This_Stack  ->  This_Stack) , 

Width  ->  0)  ; 

Text  10 .New  Line  ; 


end  loop  Display_Elements  ; 


k*' v  an  v  a1 1  v;  ww  w jwjt <jv ia> m w  w lvw  in we  iw.’v ■jvv’viwjv 'jvvrirvvrum iwnjeiwi  iwiue  uw  in iwro- 


with  Bounded_Stack  ; 
with  Text_IO  ; 

procedure  Second  Test_Of  Bounded  Stack  is 


—  This  program  unit  shows  how  a  stack  data  structure  can  be  used  to 

—  evaluate  simple  POSTFIX  expression  (also  known  as  REVERSE  POLISH) . 

—  Second_Test_Of__Bounded_Stack  will  first  prompt  the  user  for  a  file 

—  name  of  a  data  file  that  contains  postfix  expression  separated  by 

—  carriage  returns.  These  expressions  should  only  contain  single- 

—  digit  numbers  and  the  following  operators:  "*",  and 

—  "$"  (exponentiation) .  Also,  there  should  not  be  any  SPACES  between 

—  operators  or  operands .  Examples  of  valid  postfix  expressions  : 

1.  98+42*/89-+  (  i.e.,  ( (9+8) / (4*2) ) +(8-9)  ) 

—  2.  344+*  (  i.e.,  (4+4)*3  ) 

—  Second_Test_Of_Bounded_Stack  will  output  the  following  after  each 

—  successive  iteration  through  the  main  loop  (see  code  below) : 

—  CURRENT  STMBOL  read  from  the  input,  VALUE  OF  LEFT  OPERAND, 

—  VALUE  OF  RIGHT  OPERAND,  and  CONTENTS  OF  STACK. 

—  Written  by  Johan  Margono  and  reviewed  by  B.  Balfour,  E.  Berard, 

—  and  G.  Russell. 


Version  Author  Date 

1.0  J.  Margono  8  Jul  1985 

(c)  1986  EVB  Software  Engineering,  Inc. 


Reason 


package  New_Stack  ia  new  Bounded_Stack  (Element  «*>  Integer)  ; 

package  Number_IO  ia  new  Text_IO .  Integer_IO  (Num  ->  Integer)  ; 

Operand_Stack  :  New_Stack . Stack  (Maximum_Length  ->  80)  ; 

Left_Operand  :  Integer  :«■  0  ; 

Right_Operand  :  Integer  :»  0  ; 

Symbol  :  Character  ; 

Result  :  Integer  :■  0  ; 


File_Name 

Length 

My__File 


String  (1  ..  80)  ; 
Natural  ; 

Text_IO . File_Type  ; 


procedure  Display_Contents_Of  (This_Stack  :  in  New_stack . Stack)  is 

—  displays  the  contents  of  a  stack  showing  stack  elements  from 

—  top  to  bottom 

begin  —  Display_Contents_Of 


for  Element_Index  in  1  . . 

New_Stack.Number_Of_Elements 

(In_This_Stack  *■>  This_Stack)  loop 


Number_IO . Put (Item 
Width 

Text  IO.Put("  ")  ; 


->  New_Stack.Peek (At_Element 

In  This  Stack 


->  3)  ; 


->  Element_Index, 
**>  This  Stack) , 


end  loop  ; 
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end  Display_Contents_Of  ; 


function  Symbol_To_Natural  (Symbol  :  in  Character)  return  Natural  is 
Returns  the  integer  representation  of  a  character  which 
—  represents  a  decimal  digit, 
begin  —  Symbol_To_Natural 

return  Character 'Pos (Symbol)  -  Character 'Pos (’ 0 ' )  ; 

end  Symbol_To_Natural  ; 


function  Is_Digit  (Symbol  :  in  Character)  return  Boolean  is 

—  Returns  True  if  the  argument  is  a  character  which  represents 

—  a  decimal  digit . 
begin  —  Is_Digit 

return  Symbol  in  'O'  . .  ' 9 '  ; 

end  Is_Digit  ; 


begin  —  Second_Test_Of_Bounded  Stack 


Text_IO.Put  (Item  ->  "Enter  file  name  :  ")  ; 

Text_IO.Get_L.ine  (Item  ->  File_Name,  Last  ->  Length) 
Text_IO . Open  (File  ->  My_File, 

Mode  ->  Text_IO.In_File, 

Name  ->  File_Name(l  ..  Length))  ; 


while  not  Text_IO.End_Of_File  (File  ->  My_File)  loop 


—  display  header 
Text_IO .  New_Line  ; 
Text_IO.Put  (Item 

Text_IO.Set_Col  (To 
Text_IO.Put  (Item 

Text_IO . Set_Col  (To 
Text_IO.Put  (Item 

Text_IO.Set_Col  (To 
Text_IO.Put  (Item 

Text_IO . Set_Col  (To 
Text  10. Put  Line  (Item 


->  "SYMBOL")  ; 

->  15)  ; 

->  " LEFT_0P  ERAND " )  ; 
->  30)  ; 

->  "RIGHT  OPERAND")  ; 
->  45)  ; 

->  "RESULT")  ; 

->  60)  ; 

->  "STACK")  ; 


while  not  Text_IO.End_Of_Line  (File  ->  My_File)  loop 
Text_IO.Get  (File  ->  My_File,  Item  ->  Symbol)  ; 


if  Is_Digit (Symbol  ■>  Symbol)  then 


New_Stack.Push (This_Element  ->  Symbol_To_Natural (Symbol) , 
Into_This_Stack  ->  Operand_Stack)  ; 

else  —  symbol  must  be  an  operator 

New_Stack .  Pop  (Top_Element  *•>  Right_Operand, 
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Off_Thia_Stac)c  ->  Operand_Stack)  ; 

New_Stack.Pop  (TopJSlement  ->  Left_Operand, 

Of f_This_Stack  ->  Operand_Stack)  ; 

caaa  Symbol  is 
whan  '  +  •  -> 

Result  :™  Left_Operand  +  Right_Operand  ; 

whan  -> 

Result  :■  Left_Operand  -  Right_Operand  ; 
whan  ' * 1  -> 

Result  left_Operand  *  Right_Operand  ; 

whan  •/•  -> 

Lt  Right_Operand  /-  0  than 

Result  :»  Left_Operand  /  Right_Operand  ; 

alaa 

Result  :■  0  ; 

and  if  ; 

whan  ' S '  -> 

Result  Left_Operand  **  Right_Operand  ; 

whan  othara  ■> 

null  ; 

.  and  case  ; 

New_Stack.Push  (This_Eleraent  ->  Result, 

Into_This_Stack  ->  Operand_Stack)  ; 

and  if  ; 

Text_IO.Put  (Item  ->  Symbol)  ; 

Text_IO . Set_Col  (To  ->  15)  ; 

Number_IO . Put  (Item  ->  Left_Operand,  Width  ->  3) 

Text_IO.Set_Col  (To  ->  30)  ;  ~ 

Numbar_IO.Put  (Item  ->  Right_Operand,  Width  »>  3) 

Text_IO.Set_Col  (To  ->  45)  ; 

Number_IO.Put  (Item  ->  Result,  Width  »>  3)  ; 

Text_IO.Set_Coi  (To  ->  60)  ; 

Display_Contents_Of  (This_Stack  ->  0perand_5tack)  ; 
Text_I0 . New_Line  ; 

and  loop  ; 

Text_I0 . Skip_Line  (File  ->  My_File)  ; 

New_Stack.Pop  (Top_Element  m>  Result, 

Of f_This_Stack  ->  Ope rand_S tack)  ; 
Text_IO.Put  (Item  *■>  "Final  result  :  ")  ; 

Number_IO.Put  (Item  ->  Result)  ; 

Text_I0 . New_Line  ; 

—  re-initialize  operands  and  result 
Left_Operand  0  ; 

Right_Operand  :■  0  ; 
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Result 


0  ; 


end  loop  ; 

Text_IO. Close  {File  «>  My_File)  ; 
end  Second  Test  Of  Bounded  Stack  ; 
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ABSTRACT 

This  paper  is  based  on  extractions  from  the  CODSIA  Task  Group  2I-X3  Report 
on  the  DOO-STO-2147(SOS)  Package  Coordination  Review. 

The  development  of  DOO-STD-2147  Software  Development  Standards  (SDS) 
Package  is  one  of  the  mast  complex  and  comprehensive  standards  development 
efforts  undertaken  by  the  Department  of  Defense  and  the  defense  industry.  The 
SDS  Package  development  spans  a  4  year  period  from  April  1979  through  3une  1985 
with  implementation  and  revision  efforts  projected  into  the  next  decade.  Over  300 
individuals  and  130  corporations  and  Government  components  participated  in  this 
joint  effort  consisting  of  three  Government  sponsored  workshops,  five  industry  (EIA) 
sponsored  workshops,  and  three  review  cycles  containing  approximately  12,000 
review  comments..  The  DOD-STD-2147  development  is  a  significant  departure  from 
a  conventional  defense  standards  development  approach  and  can  be  used  as  a  future 
model  for  improving  standards  development  process  in  the  mission  critical  computer 
resources  area. 

The  evolution  of  the  SDS  Package  is  based  on  an  Issue  Driven  Approach  (IDA) 
which  Joe  uses  on  the  root  causes  of  the  review  comments  rather  than  fixing  on  the 
apparent  problem.  IOA  considers  conflicting  goals,  as  well  as  alternative  methods 
of  solution  starting  from  raw  comments,  to  root  concerns,  to  basic  issues.  Once 
an  issue  is  identified,  it  remains  oh  the  list,  permitting  traceability  and  follow-up 
to  assure  its  continued  resolution.  This  issue-driven  approach  makes  the  integration 
of  conflicting  factors  manageable  through  an  Incrementally  evolving  negotiation 
process  between  DoO  and  industry  representatives. 

The  DOD-STD-2147  Standards  Package  was  released  for  DoO-wide  use  on  4 
June  1913  and  is  based  on  final  or  interim  solutions  to  33  issues  extracted  from 
12,000  raw  comments.  Out  of  this  total.  Revision  A  work  is  continuing  on  18 
issues  with  interim  solutions,  which  require  extensive  research  and  development. 
Many  of  these  open  issues  are  identical  to  those  being  addressed  by  the  other  DoO 
software  initiatives:  Ada,  the  STARS  Program,  and  the  Software  Engineering 
Institute  (SE1).  Therefore,  it  is  recommended  that  these  initiatives  should 
participate  in  the  3oint  Logistic  Commanders/Computer  Resources  Management 
(3LC/CRM)  SDS  initiative  so  as  to  accelerate  the  resolution  of  these  longer  term 
SDS  issues. 

This  paper  discusses  the  3LC  SDS  Initiative  and  it  elaborates  on  the  issue- 
driven  approach  by  describing  the  concept  and  providing  the  status  and  description 
•I  the  33  issues  encountered  during  the  DOD-STD-2147  development.  This 
discussion  also  provides  plans  for  the  resolution  of  the  Revision  A  open  issues  and 
the  implementation  of  DOD-STD-2147  in  the  DoD  and  industry. 
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This  paper  will  review  the  SDS  process  and  the  lessons  learned  as  they  relate 
to  future  defense  standards  developments.  The  issue-driven  approach  will  be 
described,  as  well  as  a  review  and  description  of  the  plans  for  DOD-STD-2167 
implementation  and  the  resolution  of  Revision  A  open  issues.  Towards  this  goal, 
this  paper  is  presented  in  the  following  five  sections: 

1.  Section  I  -  provides  an  overview  of  the  SDS  Package  development 
process. 

2.  Section  2  -  describes  the  issue-driven  approach. 

3.  Section  3  -  reviews  the  status  of  the  35  SDS  development  issues. 

4.  Section  4  -  describes  the  3oint  Logistics  Commanders/Computer 
Software  Management  (3LC/CSM)  Subgroup  and  Council  of  Defense 
and  Space  Industry  Associations  (CODSIA)  Task  Croup  21-S3  plans 
lor  the  resolution  of  Revision  A  open  issues  and  DOD-STD-2167 
implementation. 

3.  Section  3  -  summarizes  the  results  of  the  3LC  SDS  initiative, 
acknowledgements,  conclusions,  and  recommendations. 


SECTION  I.  OVERVIEW  OF  THE  SOS  PACKACE  ANO  ITS  DEVELOPMENT 

PROCESS 

The  SOS  Package  has  evolved  through  3  public  review  cycles,  and  13 
document  versions  with  12,000  comments  and  33  issues  addressed.  It  has  been  a 
massive  elfort  based  on  the  best  of  Government  and  industry  voluntary  standards 
participation  and  contractor's  efforts.  The  total  effort  it  estimated  at  $10  million 
with  a  30/30  split  between  voluntary  efforts  and  Government  funding.  The  process 
contains  lessons  learned  and  sets  a  standard  for  the  improvement  of  future  defense 
standards  development  efforts. 

This  section  defines  the  defense  software  standards  problem,  provides  an 
overview  of  the  SDS  development  process  and  characterizes  the  evolving  SDS 
product. 

A.  TIC  PROBLEM  ANO  SOS  OBJECTIVES 

Mission-Critical  Computer  Resources  (MCCR)  are  a  key  element  within  modern 
defense  systems.  Efficient  and  effective  development  and  management  of  these 
resources  is  fimdamental  to  system  development,  Interoperability  and  longevity  - 
three  key  factors  which  will  determine  the  success  of  our  defense  in  coming  years 
and  its  cost.2 

In  the  mid-1970s,  studies  were  conducted  by  the  DoD  Indicating  serious 
performance  problems,  schedule  slippages,  and  cost  problems  with  practically  all 
major  weapon  systems.  Much  of  this  was  directly  related  to  software  associated 
with  the  defense  systems. 

Following  these  studies,  a  tmiform  computer  resource  management  policy, 
DODD  3000.29  and  DOOI  3000.31,  was  Introduced  by  05D  covering  all  DoO 
embedded  computer  applications.  The  Implementation  of  this  policy  in  MCCR 
management  and  the  HOC  development  and  usage  enforcement  has  been  reasonably 
successful.  The  other  areas  targeted  for  correction  werct  (1) 
coordination  ol  DoD  software  RAD,  which  has  since  evolved  Into  the  STARS 
Program  and  the  Software  Engineering  Institute,  and  (2)  software  development 
standards. 

Current  generation  ol  DeO  software  development  standards  such  as  MIL- 
5TD-I679  and  MIL-STD-490  have  evolved  ad  hoc  over  a  period  of  two  decades.  A 
number  of  defense  system  and  software  problems  in  the  1970s  and  early  19»0s  are 
traceable  to  problems  with  software  acquisition,  development,  and  support  policies 
and  standards.  These  problems  inciudet 

o  Service  and  agency  unique 

o  Inconsistent  terminology  and  requirements 

o  Neglect  of  various  aspects  of  software  acquisition  development  and 
support 

o  Incompatibility  with  modem  methods  of  developing  software 

o  Prescribed  requirements  which  are  unsupported  oy  documentation 
system 

o  Requirements  often  established  by  Implication 


e  Requirements  which  ire  subjective  and  cannot  be  easily  measured 

o  Not  designed  for  tailoring  as  a  function  of  project  size  or  software 

category 

Conflicting,  redundant,  and  in  some  cases,  nonexistent  software  development, 
acquisition,  and  support  policies  and  standards  frequently  result  in: 

o  Confusion  in  the  program  office 

o  Duplication  of  effort 

o  Contractors  maintaining  multiple  management  systems 

o  Adding  unnecessary  costs  to  the  software  acquisition  process 

o  Inability  to  focus  and  apply  software  RAD  efforts  and  accelerate 
technology  transfer  and  insertion 

The  JLC  software  standard! ration  program  objectives  were  jointly  developed 
by  DoO  and  industry  participants  during  the  Monterey  I  workshop.  These  objectives 
produced  a  complete  and  consistent  set  of  tri-service  software  accyjisition, 
development,  and  support  policies  and  standards  which: 

o  Establish  a  well-defined  and  easily  understood  software  acquisition 
and  development  process 

o  Provide,  adequate  visibility  during  software  development  and 
acquisition 

o  Reduce  confusion  and  eliminate  conflicts  in  existing  standards 
o  Are  compatible  with  modern  methods  of  developing  software 
o  Provide  cost  benefits  over  the  entire  life  cycle 
o  Increase  probability  of  obtaining  quality  software 

B.  THE  SOS  PACKAGE 

A  multi-service  group  in  the  DoO,  the  Joint  Logistics  Commanders  (JLC),  is 
developing  a  new  software  development  standards  package.  This  package  is  the 
result  of  the  initiative  undertaken  by  JLC/Joint  Policy  Group  on  Computer 
Resource  Management  (JLC/CRM)  In  April  1979.  The  following  actions  were 
identified  by  the  JLC  Workshop,  identified  as  Monterey  It 

1.  Develop  a  general  tri-service  policy  framework  for  software 
acquisition  that  addresses  the  entire  software  life  cycle  and 
provides  uniform  terminology  and  definitions. 

2.  Develop  uniform  military  standards  for  use  by  all  services  and 
agencies  consistent  with  the  policy  framework. 

X  Define  and  develop  a  comprehensive  set  of  DIDs  for  all  services 
and  agencies  which  support  the  acquisition  policy  and  standards. 

The  work  Initiated  at  Monterey  I  culminated  in  the  release  of  the  Software 
Development  Standards  (SDS)  Package  9  June  1913  which  consists  of: 

I.  Joint  Regulation,  Management  of  Computer  Resources  in  Defense 
Systems 


2.  DOD-STD-2167,  Defense  System  Software  Development 

3.  An  integrated  and  tailorable  set  of  2*  Data  Item  Descriptions 
(DIDs)  grouped  into  four  areas: 

o  3  management  DIDs 

o  9  design  documentation  DIDs 

o  a  test  documentation  DIDs 

o  C  support  documentation  DIDs 

a.  Updates  to  software  aspects  of  the  following  three  existing 
standards: 

o  MIL-STD-*13A,  Configuration  Management  Practices  for 
Systems,  Equipment,  Munitions  and  Computer  Programs 

o  MIL-STD-490A,  Specification  Practices 

o  MIL-STD-I321B,  Technical  Reviews  and  Audits  for  Systems, 
Equipments  and  Computer  Programs 

An  additional  component  of  the  JLC  software  standards  package  is  the  draft 
DOD-STD-2161,  Software  Quality  Evaluation  and  its  2  associated  DIDs. 

C.  THE  SOS  PACKAGE  DEVELOPMENT  STAGES 

During  the  evolution,  from  1979  through  1913,  the  SDS  Package  progressed 
through  the  following  stages  and  steps: 

1.  JLC  Monterey  I  Workshop:  April  1979 

2.  JLC  Monterey  II  Workshop:  June  1911 

3.  Draft  DIDs  (TRW)  and  standards  ODRC)  development:  1910-1912 
9.  .Draft  Review  (Cycle  !h  June  1912  to  May  1913 

o  First  Covernment/lndustry  review 

o  E1A  Dallas  Workshop*  September  1912 

o  E1A  and  JLC/CSM  review  meetings 
o  Document  set  rewrites 

3.  Select  Panel  Review  (Cycle  2h  May  1913  to  January  191* 
o  E1A  and  Select  Panel  Review:  May  1913 
o  Select  Panel  Meeting:  May  1913 

o  EIA  Los  Angeles  Workshop:  June  1913 

o  EIA  Phoenix  Workshop:  September  1913 
o  CODS1A  Task  Croup  21-13  formation:  September  1913 
o  JLC  Orlando  I  Workshop:  October  1913 
o  Document  set  rewrites:  Jtate  to  December  1913 
CODS1A  Review  (Cycle  Jh  January  191*  to  June  1913 
o  Formal  coordination  review:  January-April  191* 


o  CODSIA  and  3LC/CSM  review  meetings  and  workshops 

o  EIA  Tampa  Workshop:  September  1 98* 

o  Document  set  rewrites:  June  19X*  to  May  19X3 

o  DMSSO  review,  approval  and  distribution:  January  to  June 
19X3 

.The  standards  package  dated  *  June  19X3  was  released  for  DoD-wide  use  in 
July.  With  the  completion  of  Review  Cycle  3  and  release  of  the  standards 
package,  the  following  two  parallel  stages  of  DOD-STD-2167  development  are 
underway! 

7.  DOD-STD-2167  Implementation  in  DoO  and  industry 
o  EIA  St.  Louis  Workshop!  September  19X3 

X.  DOD-STD-2167  Revision  A  planning  and  development 
o  EIA  St.  Louis  Workshop!  September  19X3 

D.  A  BROADLY  BASED  PUBLIC  REYSW  AND  PARTJOPATJCN  PROCESS 

DOD-STD-2167  is  applicable  to  the  complete  software  life  cycle  and  the  full 
range  of  Jefense  software  applications.  For  example,  it  addresses  defense  software 
in  full-scale  development,  as  well  as  firmware  and  reusable  or  commercial 
software.  It  has  many  complex  interfaces  to  related  engineering  disciplines, 
including  project  management,  system  engineering,  configuration  management,  and 
quality  evaluation.  This  complex  scope  and  nature  of  DOD-STD-2167  dictates  the 
need  for  broad  public  review  and  participation  by  all  segments  of  DoO  and  Industry 
affected  by  the  standard. 

The  industry  participation  from  Monterey  I  through  CODSIA  Review  Cycle  3  Is 
summarized  in  Table  1-1.  While  a  total  of  6X  corporations  participated  in  some  of 
the  SOS  development  and  review  activities,  six  corporations  (GE,  IBM,  Logicon, 
Sperry,  Tl,  and  TRW)  participated  in  ail  six  workshops  and  reviews.  Boeing,  DRC, 
Hughes,  Singer,  and  SOC  participated  in  five  of  the  SDS  activities.  The 
corporations  listed  represent  practically  all  major  segments  of  defense  software 
applications  and  a  number  participated  through  more  than  one  industry  association 
as  indicated  in  Table  l-i.  In  some  cases,  different  divisions  of  the  same 
corporation  are  represented  In  different  industry  associations,  and  thus  have 
submitted  a  unique  set  of  review  comments.  In  other  cases,  the  tame  set  of 
review  comments  was  submitted  to  more  than  one  industry  association.  These 
rethmdant  comments  were  deleted  during  the  review  process  and  do  not  appear  in 
the  statistics.  The  CODSIA  coordinated  review  process  considered  all  comments 
regardless  of  source  or  statistical  significance. 

E.  SOS  PACKAGE  EVOLUTION 

Thirteen  drafts  of  the  SDS  Package  were  developed  by  the  contractor  (DRC). 
These  drafts  were  reviewed  by  Industry,  DoO  components,  3LC/CSM  Subgroup, 
CODSIA,  DMSSO,  and  EIA  SDS  review  committee  during  the  three  review  cycles  as 
summarized  in  Table  1-2. 

During  review  cycle  I,  the  rework  of  the  5D5  Package  by  DRC  was  based  on 
DoD  components  and  industry  detailed  comments.  Little  use,  if  any,  was  made  of 


TABLE  1.2 

OVERVIEW  OF  THE  SDS  PACKAGE  EVOLUTION 


Document  Set  Version 

Reviewed  By 

Review  Cycle  1: 

April  13,  1982  Draft  Review 

Industry 

DOD  Components 

Review  Cycle  2: 

April  1913  Select  Panel  Review 

Select  Panel  ft  ElA 

JLC/CSM 

July  30,  I9S3 

ElA 

JLC/CSM 

August  31,  I9S3 

ElA 

JLC/CSM 

Review  Cycle  3* 

December  9,  1913  •  Formal  Review 

Industry 

DOD  Components 

May  191*  -  Issue  Resolution* 

CODSLA 

JLC/CSM 

July  198*  -  Issue  Resolution  * 

COOSIA  ft  ElA 

JLC/CSM 

October  19S*  -  Issue  Resolution* 

CODSIA 

JLC/CSM,  DOD 

December  13,  19S*  -  Issue  Resolution* 

CODS1A  (Observer) 

JLC/CSM 

January  13,  1983  -  Refinements* 

CODSIA  (Advisor) 

JLC/CSM 

January  30,  1983  -  Refinements* 

CODSIA  (Advisor) 

JLC/CSM 

May  1983  •  Refinements 

- 

DMSSO 

June  *,  1983  -  Formal  Release 

— 

DMSSO 

NOTE:  •  Working  drafts  for  incremental  Issue  resolution.  A  limited  number  of 
working  drafts  were  distributed  for  Industry  review. 


the  guidance  provided  by  the  ElA  13  major  Issues  and  the  AIA  3  objections  and  13 
concerns.  Due  to  the  complexity  of.  the  Issues  and'  the  approach  used,  little 
progress  was  made  during  the  first  rework  cycle  to  address  industry's  concerns.  To 
arrive  at  a  standard  acceptable  to  Industry  and  to  keep  abreast  of  rapidly  moving 
software  technology  required  a  different  approach.  The  .Issue-driven  approach  was 
proposed  by  ElA  and  adopted  by  3LC/CSM  during  the  select  panel  review  meeting 
2*-26  May  1983  and  subsequently  used  during  review  cycles  2  and  3. 

Further,  If  the  standard,  was  to  be  developed  In  a  timely,  technology 
responsive  manner,  close  cooperation  between  the  JLC/CSM  Subgroup,  the  CODSLA 
Task  Croup,  and  the  SDS  development  contractor  was  mandatory.  Such  an  Iterative 
and  cooperative  resolution  of  Issues  was  not  Implemented  dtelng  the  draft  review 
cycle  I  and  resulted  in  a  failure  to  resolve  critical  Issues  Identified  by  ElA  and 
AIA.  During  subsequent  review  cycles,  on  assignment  from  the  JLC/CSM  Subgroup, 
DRC  successfully  recorded  the  essence  of  the  Iterative  negotiations  between  the 
Government  and  industry  (CODS1A)  representatives  on  the  complex  Issues  tmder 
discission.  As  a  result,  during  cycle  2  and  3,  they  were  able  to  ad|ust  the  wording 
In  the  standard,  DlDs  and  related  documents  to  correspond  with  the  agreements. 
This  critical  contribution  to  the  process  should  be  recognised  for  subsequent 
Revision  A  and  future  defense  standards  activities. 

P.  AN  BSUE  DRIVEN  REYCV  APPROACH 

The  evolution  of  the  SDS  Package  is  based  on  an  .Issue-Driven  Approach  (IDA) 
which  was  conceived  by  the  ElA  SDS  review  task  group  chairman,  CMe 
Goiubjatnikov  from  General  Electric  in  June  19S2  and  applied  during  the  ElA  DOD- 


STD-5D5  workshop*  in  Dallas,  Texas,  September  20-26,  1982.  The  approach  was 
subsequently  adopted  by  both  3LC*'*  and  the  select  panel  during  the  second  review 
cycle  in  Wilmington,  Mass  during  May  1983.  During  the  third  review  cycle,  IDA 
was  further  refined  by  CODSIA  Task  Croup  and  3LC/CSM  Subgroup.  The  adopted 
review  approach  is  further  described  in  Section  2  of  this  report. 

The  list  of  SDS  issues  evolved  during  the  three  review  cycles  as  shown  in 
Table  1-3. 

TABLE  1-3 


SUMMARY  OF  COMMENTS  PER  CYCLE  AND  ISSUE  EVOLUTION 


Review  Cycle 

Raw  Comments 

Issues 

(Per  Cycle) 

New 

Cumulative 

Cycle  1 

E1A 

>370  l  3|10 

13 

13  (EIA) 

Other 

3810  J 

18  (AIA) 

Cycle  2 

EIA 

768 

11 

26 

3LC  Select  Panel 

m 

18 

62 

Cycle  3 

Industry 

2UOl  3881 

2 

66  (Beginning  of  cycle) 

DOD 

3601  J 

11 

33  (End  of  cycle) 

TOTAL 

11,829 

The  initial  set  of  13  Issues  was  Identified  by  the  E1A  Dallas  Workshop*  during 
cycle  I.  In  a  similar  vein,  the  AIA  cover  letter  to  3LC/CSM  during  cycle  I 
review  identified  18  general  issues.  These  two  lists  had  a  high  degree  of 
commonality:  the  original  list  was  expanded  to  *2  during  the  select  panel  review 
cycle  2.  At  the  completion  of  COQSIA  review  cycle  3,  a  total  of  33  issues  had 
been  identified  and  addressed.  This  list  of  issues  is  discussed  in  Section  3  of  this 


SECTION  2.  THE  ISSUE  DRIVEN  APPROACH  0DA) 


A  successful  standard  In  an  area  of  rapidly  moving  technology  must  be 
technically  sound,  adaptive  to  changes  In  technology,  and  broadly  supported  by  a 
wide  variety  of  developers  and  users. 

DOD-5TD-2167  Is  such  a  comprehensive  standard,  resulting  from  the  joint 
efforts  of  the  DoD  and  the  defense  industry.  DOD-STD-SDS  development  process 
is  based  on  IDA  and  represents  a  significant  departure  from  the  conventional 
approaches  to  defense  standards  development.  The  IDA  addresses  five  fundamental 
Issues  inherent  In  defense  standards  development  process 

o  A  systematic  approach  to  Issue  resolution  In  a  complex  and  rapidly 
moving  technology  area. 

o  Due  process  and  consensus  development. 

o  Efficiency  and  effectiveness  of  voluntary  standards  process. 

o  Active  versus  reactive  standards  development 

o  Accelerated  technology  transitioning  from  RAD  to  battle  operation¬ 
al  environment. 

This  section  will  describe  the  IDA  concept  and  summarise  the  lessons  learned 
In  applying  IDA  during  the  DOD-STD-2147  development  process.  The  IDA  concept 
can  be  further  refined  based  on  lessons  learned  and  used  as  a  model  for  the 
development  of  future  standards  in  the  MCCR  area,  such  as  the  computer  systems 
interface  standards  proposed  by  the  CODS1A  and  the  Defense  Computer  Resources 
Board  (DCRB). 

A.  DEFENSE  STANDARDS  REQUIREMENTS 

Properly  conceived  and  useable  standards  are  essential,  both  In  the  private 
sector  and  In  defense,  to  cope  with  Inc ree sing  technical  complexities.  Software 
development  standards,  In  particular,  are  becoming  Important  as  a  means  to 
mitigate  problems  encountered  ht  software  development  end  the  acqjisitlon  and 
operational  use  of  computer  based  networks,  systems  and  prodjcts.  This 
observation  Is  supported  by  the  rapidly  accelerating  software  standards  development 
activities  in  the  early  1910s  with  such  national  voluntary  standards  bodies  as  EEF 
and  ASTM,  and  international  bodies,  such  as  ISO  and  IRC. 


As  U.S.  defense  posture  Is  critically  dependent  on  software  and  resulting 
defense  systems  automation,  it  Is  Imperative  that  the  DoD  maintain  a 
International  leadership  position  In  software  standards  development  vouch  u  a 
complex  and  extremely  slow  process.  The  adoption  of  national  and  International 
standards,  while  consistent  with  DoO  policy  on  volimtary  stamtardt,  would  delay  the 
Introduction  of  modem  software  engineering  practices  in  UJS.  defense  ******** 
3-10  years.  The  development  of  modem  software  engineering  prset^es  ano 
standards,  end  the  resulting  leadership  In  software  engineering.  Is  fundwnentai  to 
the  United  States  defense  strategy  based  m  •*  force  multiplier  conexp  , 
therefore,  must  be  aggressively  purstfd.1 

Beyond  commercial  software  requirements,  the  defense  software  •J“**"J* 
must  also  emphasize  areas  unique  to  the  defense  systems,  such  as  **urity 
phased  acquisition  Ufa  cycle  of  defense  systems.  At  the  eame  time,  me 


software  standards  should  maintain  compatibility  in  direction  with  national  voluntary 
standards  in  areas  such  as  commercial  and  reusable  software  and  coding  standards. 
Additional  defense  software  requirements  also  exist  internationally  to  assure 
compatibility  with  standards  within  the  NATO  defense  alliance. 

B.  A  SYSTEMATIC  APPROACH 

The  IOA  focuses  on  the  root  of  the  public  review  comments  rather  than  fixing 
only  the  locally  apparent  problems.  It  considers  conflicting  goals,  as  well  as 
alternative  methods  of  solution  starting  from  raw  comments,  to  root  concerns,  to 
the  basic  Issues.  Once  an  Issue  is  Identified,  it  remains  on  the  list,  permitting 
traceability  and  follow-up  to  assure  its  continued  resolution.  The  IDA  makes  the 
complex  process  of  Integrating  the  diverse  and  conflicting  factors  manageable 
through  an  incrementally  evolving  negotiation  process.  Further,  this  method 
provides  a  mechanism  to  assure  currency  with  technology  and  changes  in  policy  and 
business  practice.  The  IDA  is  based  on  three  major  activities: 

o  Analysis  of  raw  comments  and  bottom-up  synthesis  of  concerns  and 
issues. 

o  Top-down  analysis  and  resolution  of  issues  and  correlation  with 
other  Isms  to  resolve  conflicts  and  assure  overall  compatibility. 

o  Review  of  detailed  comments  for  each  section  and  paragraph,  and 
implementation  of  action  items  resulting  from  Issue  resolutions 
which  Is  accomplished  by  rewriting  affected  sections  and  paragraphs 
of  the  standards  and  DID*. 

The  five  levels  of  the  IDA  structural  concept  is  depicted  In  Figure  2- It 
fundamental  Issues,  Isms,  subiiMS,  concerns  and  comments.  The  number  of 
elements  at  all  five  levels  at  the  end  of  CODSiA  review  cycle  are  summarized  In 
the  figure.  As  the  IDA  structure  Is  fundamental  to  the  approach,  the  Individual 
levels  are  defined  next. 

1.  FUNDAMENTAL  BSUES 

These  broad  and  pervasive  Iims  are  (he  primary  MCCR  life  cycle  cost  and 
schedule  drivers  and  are  the  basis  for  many  Industry's  objections  to  any  standard, 
including  DOD-5TD-3D5.  They  ares 

o  Significant  and  unnecessary  cost  escalation  (cost  drivers) 

o  Unnecessarily  constraining  and  restrictive 

o  Isolation  of  software  from  the  defense  system  and  system 
engineering  process 

o  Excessive  data  requirements 

Generally  little  corrective  action  can  be  taken  at  the  fundamental  issues 
level,  as  these  Isms  are  too  broad  and  pervasive.  The  fundamental  issues  are 
mapped  into  a  number  of  different  issues  at  the  next  lower  level. 

2.  BSUES 

Issues  are  manageable  areas  of  dispute,  concern  or  controversy  as  grouped  by 
life  cycle,  technology,  methodology  or  project  management  considerations.  They 


SDS  DEVELOPMENT  APPROACH 


£  2 

i  3 

<  o 

Z  UJ 

*  oc 

?  s 

a. 

o  £ 

h 


issues 


SUBISSUES 


u  n 
a.  10 
?  2 

g  5 


CONCERNS  (PER  CYCLE) 


COMMENTS  (PER  CYCLE) 


SOS  DEVELOPMENT  IS  BASED  ON  TOP  DOWN  ANALYSIS 
ANO  BOTTOM-UP  COMMENTS  DISPOSITION 


freqjently  correspond  to  general  or  essential  comments  received  during  the  SDS 
Package  review.  A  total  ol  JJ  issues  were  identified  during  the  three  CODSIA 
review  cycles.  These  issues  are  discussed  in  Section  3  of  this  report.  Most 
complex  SDS  iss^s  cannot  be  resolved  at  the  issue  level  but  must  be  further 
subdivided  into  subissues  for  their  resolution.  Issues  represent  a  permanent 
structure  and  are  continued  through  the  different  SDS  review  cycles  to  verify  their 
closure  or  to  provide  for  future  technology  insertion  and  changes. 

3.  SUB  ISSUES 

Subissues  are  the  logical  substructure  of  the  more  complex  Issues. 

*.  CONCERNS 

Concerns  are  collections  of  related  aets  of  detailed  SDS  review  comments 
received  for  each  review  cycle.  They  exist  only  for  the  duration  of  the  specific 
review  cycle.  They  are  frequently  related  to  a  specific  SDS  section  and  paragraph. 
Concerns  may  be  used  for  making  implementation  changes  to  a  specific  SDS 
paragraph  or  mapped  into  the  permanent  structure  of  subissues,  where  they  brcome 
part  of  an  issue  which  may  relate  to  a  large  rnenber  of  paragraphs  cutting  across 
different  standards  and  DfDs. 

3.  COMMENTS 

Comments  are  the  detailed  raw  comments  received  during  the  SDS  review 
process.  They  are  usually  referenced  against  a  specific  paragraph  of  the  standard 
or  DID.  Frequently,  comments  are  only  symptoms  of  the  more  basic  issues  which 
cut  across  the  standardfs)  and  the  D1D(s). 

C.  MJE  PROCESS  AND  CONSENSUS  DEVELOPMENT 

The  development  of  complex  defense  standards  In  areas  of  rapidly  moving 
technology  Is  a  significant  technical  and  management  challenge.  The  standard  must 
not  only  be  technically  correct  and  dynamic  but  must  also  be  broadly  accepted  and 
supported  across  a  wide  spectrum  of  defense  applications  and  functionally  different 
viewpoints. 

Defense  standards  are  usually  drafted  by  a  single  Individual,  a  single 
contractor,  or  a  single  service  or  agency  component.  For  example,  the  DOD- 
STD-2167  draft  was  developed  by  DRC  and  the  original  aet  of  DfDs  by  TRW. 
Much  less  frequently  the  standard  is  developed  by  a  DoO  or  Industry  working  group 
or  a  Joint  DoO  and  Industry  working  group.  The  writers  frequently  lack  the  broad 
spectrum  of  viewpoints  and  experiences  necessary  to  draft  a  technically  sound  and 
broadly  supported  standard  capable  of  Implementation  across  a  wide  and  diverse 
range  of  applications.  (The  early  drafts  of  DOD>STD>2i(7  and  the  related  DIDs 
are  good  examples.)  It  Is  questionable  that  any  single  individual  or  a  single 
organization  can  produce  an  acceptable  document  in  Isolation. 

The  development  of  a  draft  defense  standard  Is  followed  by  the  coordination 
review  process.  Industry  and  DoO  comments  received  during  the  coordination 
review  fall  Into  two  categories!  general  and  detailed.  The  detailed  comments  are 
referenced  against  a  specific  section  and  paragraph,  while  general  comments 
frequently  have  no  paragraph  level  references. 


The  comments  received  are  usually  processed  by  the  same  individual  or 
organization  (having  a  single  viewpoint)  which  drafted  the  standard  initially,  with  no 
or  limited  independent  checks  or  balances  provided  by  the  system.  The  specific 
comments  are  processed  by  rewriting  the  referenced  paragraphs  of  the  standard. 
Ceneral  comments  are  usually  too  difficult  for  corrective  action  and  are  frequently 
discarded  by  the  process  as  too  broad  or  too  difficult  to  resolve. 

As  was  vividly  demonstrated  during  the  first  review  cycle  of  SDS,  the  above 
described  approach  In  the  case  of  complex  standards  In  a  dynamic  technology  area 
can  result  in  a  failure  of  the  system  to  address  the  substantatlve  Issues  contained 
In  the  large  nunber  of  conflicting  and  competing  comments.  It  Is  In  this  area  that 
the  joint  steering  and  negotiation  process  by  3LC/CSM  subgroup  and  CODSIA  Task 
Croup  made  a  major  contribution  during  the  COOSLA  review  cycle.  In  Identifying 
issues,  resolving  conflicts  and  developing  broadly  based  solutions  and  thus  providing 
guidance  and  steering  to  the  SDS  contractor  developing  the  detailed  Implementation 
of  the  standard  and  the  related  DIDs,  a  significant  improvement  was  achieved  in 
the  consensus  development  process. 

The  second  major  contribution  to  the  SDS  process  was  the  informal  section 
*>y  3LC/C5M  Subgroup  and  CQDSLA  Task  Group  the  broad  principles  used  by  the 
ANSI  standards  development  process  to  assure  due  process  and  Industry  and  DoD 
consensus.  These  principles  are  summarised  below 

o  Due  Process 

•  Everyone  with  Direct  and  Material  Interest 

-  Right  to  Express  a  Viewpoint 

-  If  Dissatisfied,  to  Appeal  Any  Point 

-  Equity  and  Fair  Play 

o  Consensus 

-  Substantial  Agreement 

•  More  than  a  Simple  Majority 

•  Not  Necessarily  Unanimous 

•  All  Views  and  Objections  Considered 
Concerned  Effort  Made  Towards  Their  Resolution 

-  Formal  Voting  Evidence  If  Required 


o  Other  Considerations 

•  Conflicts  Resolved  VIA  Other  Related  Defense  Standards 

•  Avoid  Propriatory  and  Product  Bias 

D.  EFFICIENCY  AND  EFFECTIVENESS  CF  TTZ  VOLUNTARY  STANDARDS 
PROCESS 

The  following  activities  and  principles  reflect  tfte  •lessons  Warned1  or  have 
contributed  to  the  Improved  efficiency  and  effectiveness  of  the  DOD-5TD-SDS 
development  process: 

I.  SELECT  PANEL  REVIEWS 


Premature  release  of  draft  standards  for  general  public  review  and 
coordination  should  be  avoided.  The  use  of  joint  Industry  and  DoO  Workshops  or 
selected  working  groups  to  review  the  early  drafts  of  the  standard  avoids  a  large 
number  of  unnecessary  comments  during  public  review  and  the  related  processing 
costs  and  time  delays.  Such  working  groups  need  to  be  carefully  composed  to 
represent  a  balanced  cross  section  of  the  Industry. 

2.  USE  OF  CONTRACTORS  ,FOR  STANDARDS  DEVELOPMENT 

The  use  of  full  time  contractors  (e.g.t  DRC  and  TRW  for  DOD-STD-SDS)  has 
significantly  accelerated  the  process  of  developing  complex  defense  standards  In  the 
voluntary  ANSI-like  process. 

3.  USE  OF  POD  AND  INDUSTRY  STEERING  CROUP 

The  use  of  JLC/C5M  and  CODSIA  Task  Croup  as  the  technical  negotiations 
and  management  steering  group  for  the  DOD-STD-3DS  development  has  significantly 
Improved  the  quality  of  the  standard  and  the  process  of  consensus  development  and 
due  process. 

I.  USE  OF  INDUSTRY  EXPERTS 

The  use  of  industry  volunteer  experts  as  specific  Issue  coordinators  and 
problem  solution  developers  has  significantly  improved  the  quality  of  DOQ-5TD-5DS 
and  provided  the  necessary  technical  support  to  the  CODSIA  Task  Croup.  This 
technical  support  base  dwuld  be  further  expanded  to  support  the  Revision  A 
development  effort. 

E.  ACTIVE  VERSUS  REACTIVE  STANDARDS  DEVELOPMENT 

There  are  two  basic  approaches  to  standards  developments  active  and 
reactive  docwnentaion.  Active  standards  are  planned,  resulting  from  forethought  as 
to  their  need  and  content.  An  excellent  example  of  active  standards  development 
is  Mr.  Fords  dial  role  as  an  Inventor  of  a  mechanical  wagon  and  a  developer  and 
promoter  of  traffic  standards  for  his  horseless  carriage. 

Reactive  standards  result  from  a  need  for  some  controls  after  the  new 
Invention  or  product  has  been  introduced.  Current  generation  DoO  software 
standards  such  as  MIL-5TD-1<73  are  a  good  example  of  reactive  standards. 
Software,  for  a  long  time,  has  been  considered  more  of  an  art  than  engineering 
science.  Therefore,  software  practitioners  frequently  object  to  attempts  to 
establish  software  standards  as  excessive  constraints  to  their  Intellectual  and 
creative  process.  As  software  practice  matures,  and  Its  economic  and  public  safety 
Impacts  expand,  the  demand  for  software  standards  is  escalating  in  both  public  and 
private  sectors. 


As  a  result  of  DOD-STD-5DS  development,  a  fundamental  change  In  defense 
software  standards  development  has  occurred.  The  defense  Industry  has  moved 
from  reactive  standards  development  in  1373  (Monterey  I)  to  active  standards 
development  In  1313  (Revision  A).  As  is  evidenced  by  the  Issues  addressed  In  the 
Revision  A  effort,  such  an  artificial  Intel Ugence/expert  systems  (AI/E5),  we  are  not 
only  correcting  p«st  problems,  but  are  also  beginning  to  plan  standards  for 
advanced  technology  practice.^  Certainly,  It  Is  much  less  costly  to  plan  and 
Implement  standards  along  with  the  creation  of  a  new  product,  process  or 
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.  Thef*.  *7  !WOJ***|C  P”ltJort  *•*  Industry  can  take  with  respect  to 

soft  wore  standards  developments  active  and  reactive  participation.  Traditionally 
most  *ien*e  standards  are  the  result  ef  developments  by  DoD  personnel.  T& 
morf«T*e  J^sXry  *fr>er*ily  1p*rti5^*te*  I"  •  reactive  review  wrf  comment 

STl£ Vd7fTMd^£!*eTiKaIIti °"  *?,tw*r*  development  standards,  such  aa  MIL- 

3TD-1479  and  MIL-STD-I4M  were  (fcveloped  in  this  manner. 

A  wide  variety  of  software  categories,  software  development  practices,  and 
participant  s  vieyP«[i]**  »ngst  be  accommodated.  No  single  individual  or 
organization  has  all  the  retired  Insights  to  develop  an  acceptable  draft  document, 
f  *°*f  xnd  7V**  D0°  lndu,try  Participation  la  absolutely  mandatory  If 

leo^cur^’^nTLl0  lnAj,tTy  <ieT*loPer  are  to  be  produced  and 

kept  current  with  changes  In  technology  and  business  practice.  Without  active 

»"*«*  f*rtfcipatJon,  the  software  technology  is  moving  faster  Wtan  the  rate  at 
by  the  DoD*aioneCC*PUb,e  mn<^l^d,  **  developed,  coordinated,  and  approved 

The  development  of  the  DOD-STtMDS  Paciage  over  the  last  4  years,  as 
documented  in  this  report,  is  an  ojtstanding  example  of  such  DoO  and  defeme 

Irri’W?.  *» tiV*  p*rticiP*tJon  **»d  cooperation.  The  Initial  release  of  the  DOD- 
3TD-2I67  Package  Is  not  a  perfect  document,  as  Is  evidenced  by  the  number  of 
open  Issues  for  Revision  A.  At  the  same  time,  a  review  of  other  national  and 
*°,tw*r«  dtandards  development  projects  dearly  Indicates  DOD- 
5TD-2I47  to  be  •  better  and  more  cohesive  standard  than  any  other  set  of 
standards  currently  available  or  In  development. 

DOO-5TD-2147  Package  establishes  the  basic  fosmdatlon  for  next  generation 
defense  software  standards.  This  foundation  will  be  Improved  by  revisions  based  on 
*70,ut,0,’  ««d  Implementation  experiences  with  the  initial  DOD- 
5^P“2I47.  The  DOD-STD-2147  standards  foundation  will  also  be  expanded  as  the 
other  DoO  software  initiatives!  Ada,  STARS,  SEI,  and  DARPA  Strategic  Computing 
Program  become  more  dosely  coupled  with  the  3LC  SDS  software  Initiative.  Many 
of  the  unresolved  longer  term  Issues  Identified  during  the  DOD-STD-2147 
development  win  be  resolved  by  products  and  R&D  activities  resulting  from  the 
other  DoD  software  initiatives. 

P.  TECHNOLOGY  T&AMSmCMNG  PSCH  RAO  TO  BATTLZ  CfSaATSCNAL 
ENTIRCNMENT 

COD31A  Task  Croup  13-42  report  to  USDCRtf)  entitled  DoD  Management  _-nf 
f4!*??0"  *  Critical  Computer  Resources2  observes  that  technology  transitioning  from 
R«D  to  battle  environment  is  exceedingly  slow  and  a  major  issue  In  MCCR 
management.  Timely  introduction  of  standards  and  t*e!r  evolution  with  technology 
ta  a  primary  vehicle  for  assuring  technology  leadership  and  operational  effectiveness 
in  the  battle  environment. 

The  IDA,  as  demonstrated  by  DOD-STD-2147  development,  provides  the 
mechanisms  for  evolving  defense  standards  as  a  function  of  technology  developed  by 
the  public  and  private  sectors.  Issues  such  as  AI/E3  (Issues  34  through  40) 
combined  with  SDS  revision  process  and  implementation  In  the  field  provide  a 
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mechanism  for  technology  transitioning  from  early  guidance  to  preferred  practice 
and  finally  to  enforced  standards. 

Many  of  the  Issues  identified  for  DOD-STD-2167  Revision  A  are  identical  to 
the  issues  being  addressed  longer  term  by  the  DOD  software  initiatives  Ada, 
STARS^  and  5EI.  The  coupling  between  these  initiatives  and  the  JLC  software 
Initiatives  for  initial  release  of  DOD-STD-2167  was  minimal  due  to  the  early  stages 
of  these  programs.  As  the  STARS  Program  and  the  SEI  becomes  operational, 
considerable  additional  coupling  and  use  of  their  R&D  products  is  expected  for 
Revision  A  and  subsequent  revisions  of  DOD-STD-2167. 


SECTION  3.  SOS  DEVELOPMENT  ISSUES 

The  SDS  Package  is  the  product  o!  an  extensive  public  review  and 
participation  process  which  required  the  resolution  of  a  large  number  of  complex 
and  conflicting  laciors.  This  resolution  process  and  the  detailed  rationale  used  for 
the  resolution  of  the  53  specific  issues  identified  during  the  three  SDS  Package 
review  cycles  is  documented  in  CODSLA  Tuk  Croup  21-13  Report  on  the  POD- 
STD-2167  (SDS)  Package  Coordination  Review*  dated  November  1315.  . 

Not  all  of  the  issues  identified  during  the  SDS  Package  evolution  were  fully 
resolved  at  the  initial  release  of  DOD-STD-21C7.  A  number  of  issues  were 
resolved  based  only  on  interim  solutions.  Revision  A  work  is  continuing  lor  their 
full  resolution,  as  well  as  a  validation  that  the  issues  considered  closed  at  the 
point  of  initial  release  of  the  standards  package  are  actually  closed  based  on  field 
feedback. 

The  purpose  of  this  section  is  to  identify  the  35  issues  identified  during  SDS 
package  evolution  and  provide  status  as  to  their  priority  and  resolution.  The  3) 
issues  are  identified  in  Table  3-1. 

A.  ISSUE  STATUS  AT  THE  BEG2NNMG  CP  COOSIA  KEYS*  tCYCXE  3) 

Analysis  of  the  industry  review  comments  at  the  beginning  of  review  cycle  3 
revealed  several  dominant  trends.  In  addition  to  making  constructive  comments, 
the  participating  companies  expressed  their  positive  reaction  to  the  successive 
drafts  of  the  SDS  Package.  Some  respondents  observed  that  the  draft  was  already 
technically  superior  to  the  various  existing  standards  being  imposed. 

In  the  area  of  constructive  criticism,  one  dominant  thread  was  the  conviction 
that  the  standards  would  result  in  a  significant  and  unnecessary  cost  escalation  it 
released  in  their  December  S3  form.  Althoutfi  a  serious  and  fundamental  issue,  the 
COOSIA  task  group  decided  these  concerns  were  clearly  Identified  and  remedial 
action  could  be  taken  during  the  review  process.  Toward  this  end,  the  group 
identified  eight  primary  issues  and  nine  secondary  Issues  for  resolution.  The  cost 
drivers  were  included  in  the  list  of  primary  issues. 

The  eight  primary  issues  and  their  tracking  numbers  are  listed  below  in  a 
priority  order: 

1.  Issue  23t  Tailoring 

2.  Issue  %lt  Software  Development  PUe  (Alias  Folder) 

3.  Issues  1C,  17,  13,  21t  Informal  Testing 

a.  Issue  7t  Ada 

3.  Issue  ti  Firmware 

3.  Issue  C«  Systems  Interface  and  Isolation  of  Software 

7.  Issue  %3i  Automation 

3.  Issue  27:  Revision  Strategy 

A I  though  significant  changes  were  incorporated  in  the  SDS  Package  * 

December  13)  to  rescive  comments  about  SDS  being  too  constraining  and  restnctive 
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(Issue  *),  this  fundamental  issue  was  still  a  dominant  concern  among  industry 
reviewers  who  characterized  the  package  as  having  too  much  how-to  direction,  and 
verging  on  micromanagement  in  other  areas.  However,  this  fundamental  issue  was 
considered  too  general  for  corrective  action  and  was  mapped  into  three  specific 
primary  issues: 


Issue  %2:  Software  Development  Folders 
Issue  17:  Informal  Testing  Constraints 
Issue  7t  Ada"  Suitability/Compatibility 


By  successfully  addressing  these  specific  issues,  the  fwtdamental  issue  of  being  too 
restrictive  would  be  substantially  resolved. 


Some  respondents  noted  the  trend  to  Isolate  the  software  development  and 
acquisition  methodology  and  terminology  from  that  of  general  systems  engineering 
and  system  acquisition.  The  structure  of  the  SDS  activities  (e-g.,  absence  ol 
requirements  generation  methodology)  and  associated  policies  are  perceived  as 
exacerbating  this  situation.  The  Task  Croup  decided  to  address  this  fundamental 
issue,  which  requires  significant  work,  In  a  future  update  to  the  SDS  Package.  The 
decision  to  poitpone  problem  solution  to  a  future  update  merits  some  elaboration. 


The  CODSIA  Task  Croup  recognized  two  classes  of  action  recommendations: 


I)  Short  term  action  -  temporary  solutions  to  problems  requiring 
extensive  technical  work  for  Incorporation  in  the  Initial  release  of 
the  SDS  Package  (A  June  19*3). 


2)  Long  term  action  -  the  final  solutions  to  problems  which  require 
further  technical  work,  and  which  are  expected  to  be  implemented 
In  subsequent  revisions  of  the  SDS  Package. 


The  Task  Croup  created  this  distinction  because  of  pragmatic  considerations 
relating  to  the  need  for  early  release  of  the  SDS  Package  versus  the  time  and 
effort  reqjired  to  research  the  changes.  Therefore,  a  revision  to  the  Interim 
Version  Is  essential,  and  the  Revised  Version  should  be  implemented  within  2  years 
(i.e.,  June  1917).  It  should  also  be  noted  that  these  deferred  issues  have  not  been 
more  effectively  addressed  In  any  existing  software  development  standard,  so  the 
new  standard  is  not  a  regression. 


The  priority  of  the  M  Issues  identified  by  the  beginning  of  review  cycle  3 
was  established  by  the  CODSIA  Task  Croup  based  om 


The  Impact  of  the  issue  on  industry  practice. 

The  assessment  of  the  issue  status  as  to  its  resolution  based  on 
industry  comments  received  and  Task  Croup  review  of  the  SDS 

Package. 


The  relative  priority  of  the  Issues,  based  on  the  December  19*3  draft,  was 
categorized  ast 


Primary  (3  1 
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o  Secondary  (10  issues) 

o  Tertiary  (9  issues) 

o  Closed  (13  issues) 

o  Remapped  (6  isues)). 

Issue  6  (Too  constraining/restrictive)  was  considered  a  fundamental  issue  and 
excessively  broad  for  corrective  action  and  was  remapped  into  issues  number  7,  16, 
17,  IS,  21  and  *1. 

Issues  16,  17,  IS  and  21  addressing  test  related  issues  were  collected  under  a 
single  issue  16. 

B.  ISSUE  STATUS  AT  TIC  PCJNT  CP  SOS  PACKAGE  V4TT1AL  RELEASE. 

The  status  of  Issues  at  the  point  of  SDS  Package  Initial  release  Is  summarised 
in  Table  3-1.  The  status  table  includes  62  issues  identified  during  the  two  previous 
review  cycles.  Issues  63  through  33  were  added  during  review  cycle  3.  The  table 
identifies  the  COOS1A  priority  of  ail  issues  at  the  point  of  SDS  Package  initial 
release!  primary,  secondary,  tertiary,  and  closed.  The  closed  issues  are  subject  to 
validation  based  on  field  usage  feedback.  Partially  closed  issues  indicate  the 
proposed  resolution  strategy!  Revision  A,  MIL-HDBK-217,  changes  to  other  policies 
and  standards  and  revisions  to  Joint  Regulation. 

C.  LIMITED  COCftDfNATICN  AND  PROPOSED  CHANGES 

Three  sections  were  added  to  the  standard  during  December  1914  with 
essentially  no  industry  review  because  these  section  were  created  at  the  final  stage 
of  the  review  process,  when  time  did  not  permit  their  wide  circulation.  The  three 
sections  in  question  ares 

o  3.S  Software  Quality  Evaluation 

o  3.9. 1.3  Risk  Management 

o  Appendix  D  Tailoring  Guidelines 

The  first  two  were  prepared  by  the  Government  contractor  (DRC).  The  CODSIA 
Task  Group  objected  to  their  inclusion  (particularly  3.3  which  Is  voluminous)  without 
adequate  reviews.  Those  objections  were  overruled  however,  and  the  sections  were 
included  In  the  standard.  The  Appendix  D  was  prepared  by  Mr.  O.  Golubiatnikov,  a 
member  of  the  CODSIA  team,  but  was  only  reviewed  by  the  members  of  the  team 
before  being  offered  to  the  Government  for  inclusion.  It  Is  recommended  that 
each  of  these  sections  be  given  particular  scrutiny  during  upcoming  reviews. 

An  Appendix  E,  -Application  Guide  end  Example  for  Development  of  Prime 
Items  end  Critical  Items  that  Contain  Software  end  Firmware  Components-,  was 
also  prepared  by  the  EIA  members  Messrs.  O.  GdU>jatnikov  end  John  C.  •* 

the  CODSIA  team.  This  appendix  specifically  addressed  the  MIL-STD->90 
issue  number  36  and  the  related  Isolation  of  software  from  the  system  engineering 
process.  This  appendix  was  voted  and  imanimoutly  approved  by  EIA  memoe  p, 
but  did  not  receive  tmenimous  CODSIA  Task  Groi^  approval  end  thus  w 
incorporated  In  the  initai  6  June  1913  release  of  DOD-STD-2167. 


SECTION  «.  SOS  IMPLEMENTATION  AND  PLANS  FOR  REVISION  A 


The  SOS  Package  was  approved  by  DMSSO  for  DoD- wide  usage  4  June  1913. 
The  smooth  transitioning  from  a  wide  variety  of  currently  service-unique  and  single 
program  software  acquisition  practices  to  the  uniform  DOD-STD-2167  practice  and 
its  successful  implementation  and  evolution  with  technology  advances  in  DoD  and 
industry  depends  oru 

1.  Training  and  tailored  application  of  the  standards  package. 

2.  Field  monitoring  and  Implementation  feedback  to  avoid  misapplica¬ 
tion  of  the  initial  verlson  of  the  standards  package. 

3.  Continued  development  of  Improved  solutions  for  Issues  closed  for 
the  Initial  release  based  on  Interim  solutions. 

%.  Continued  evolution  of  the  SDS  Package  through  technology 
Insertion  from  public  and  private  developments. 

A.  GOVERNMENT  DCO-STD-2167  IMPLEMENTATION  PLANS 

The  JLC/CSM  Subgroup  and  the  Services  have  Initiated  a  DOD-STD-21 67 
Implementation  program.  The  major  elements  aret 

o  JLC/CSM  Subgroup  DOD-STD-21  <7  Implementation  Concept/Strategy 
Plan 

o  Servlee-tmique  DOD-S'i  D-2167  Implementation  Plans 

o  DOD-STD-21  (7  Training  Courses  at  executive,  management,  and 

technical  levels 

o  DOD-STD-21 67  (MIL-HD6K-2S7)  Handbook  development 
o  DOD-STD-2167  "Help"  line  (with  levei-of-effort  contractor  support) 
o  DOD-STD-2167  Implementation  Feedback  Survey  of  current  users 
o  DOD-STD-2167  Implementation  Evaluation 

o  Industry  and  Government  Briefings  and  Tutorials 

o  JLC  Workshops  (Orlando  II) 

As  an  example  of  the  effort  applied,  during  I9S4/I933,  the  JLC/CSM  Subgrcup 
alone  has  given  over  23  briefings  and  3  tutorials  to  Industry  and  Government  on 
the  technical  aspects  of  DOD-STD-SDS  package. 

B.  XOU5TRY  DOO-STD-2167  IMPLEMENTATION  B4TT1ATIVZ3 

To  provide  proper  DOD-STD-2167  Introduction  and  assure  Its  continued 
evolution  with  technology  and  field  feedback,  the  CODSIA  Task  Group  21-33,  the 
industry  associations  and  the  Individual  corporations  are  taking  numerous  actions. 
The  following  are  examples  of  industry  DOD-STD-2167  initiatives. 

•  Joint  InAistry  Conferences  and  Tutorials.  Dur!ngl934  and  1913  Irnkistry 
associations  iAja,  tlA,  N5LA  J  and  professional  societies  uEEE,  ACM)  have  held 
numerous  joint  Industry  conferences  focusing  on  different  aspects  of  defense 
software.  These  conferences  offer  papers  on  DOD-STD-2167  and  DOD-5TD-2163. 
Some  conferences  have  also  offered  4- hour  tutorials  on  DOD-STD-2167,  DOD- 


STD-2168,  and  Software  Standardizaton  Activities.  Additionally,  the  DPMA  has 
offered  two-day  tutorials  on  DOD-5TD-2167  and  DOD-STD-2I6J.  EIA  is  also 
offering  DOD-5TD-2167  and  DOD-5TD-2I6I  tutorials  during  its  annual  EIA  G33/3* 
workshops.  These  InAistry  association  initiatives  are  epee  ted  to  continue. 

O  EIA  Workshops  on  DOD-STD-2167  and  DOO-STD-216*  Development.  EIA 
conducted  special  panels  on  (x$D->$tD-2147  and  boiJ-S  l  D-21&i  development  Airing 
its  annual  EIA  G33/3*  workshops  In  15*1,  15S3,  198*,  and  1983.  These  workshops 
are  attended  by  both  Industry  and  Government  personnel  and  complement  the  3LC- 
sponsered  (Monterey  I,  II,  and  Orlando  I)  workshops  on  DOD-STD-SD5  development. 

These  workshop*  provide  an  opportunity  for  Government,  InAistry,  and 
academic  personnel  to  address  specific  DOD-STD-SD3  related  problems  and  issues 
and  participate  In  die  DOD-STD-SOS  Package  development  process.  The  EIA 
workshop  panels  are  led  by  CODS1A  Task  Group  members,  Industry  association 
reviewers,  Government  DOD-5TD-5D5  contractor  and  3LC/C5M  Subgroup  personnel 
and  provide  an  excellent  forum  for  resolution  of  problems  and  development  of 
recommendations  to  the  software  standard.  The:e  annual  worktops  are  expected 
to  continue. 

o  Industry  Upgrade  of  In-House  Software  Standards  and  Procures.  A 
number  of  companies  wve  already  adopted,  on  a  voluntary  oasis,  DOD-5TD-2167  as 
their  In-house  software  development  standard.  These  companies  have  acted  as 
DOD-5TD-2167  test  beds  and  provide  useful  feedback  to  the  SOS  Package 
development  during  the  second  and  third  review  cycles.  More  recently,  other 
companies  have  begun  to  upgrade  their  in-house  standards  and  proce  Aires  to  assure 
compatibility  with  DOD-STD-2147  requirements  for  contractual  compliance. 

o  Industry  Implementation  of  DOO-STP-2H7  Environments  and .  Automation 
Tools.  Trl- service '' standardization  on  a  ling*  software  oevelopment  stanoaro  w»tn 
a"  'consistent  set  of  DIDs  creates  an  environment  conAicive  to  Investments  in 
software  development  automation.  A  number  of  companies  have  ongoing  efforts  to 
automate  the  generation  of  DOD-STD-SOS  required  products.  It  Is  ejected  that 
such  environments  and  automated  tools  will  not  only  be  operated  Interrwlly  by  the 
major  system  houses,  but  wUI  also  be  offered,  as  products  by  houses  specializing  In 
marketing  software  tools  and  environment*. 

C.  ASSESSMENT  C?  DCO*STD-2tt7  OfTSaat  3Z12A3  f 

The  early  applications  of  the  3DS  Package  on  Government  proposals  and 
contracts  provides  an  opportunity  for  a  detailed  assessment  of  the  package,  •***[* 
as  a  detailed  validation  of  proper  Implementation  of  the  Issue  resolutions.  Both 
JLC/C5M  Subgroup  and  CODS  LA  are  planning  to  establish  a  joint  data  collection 
mechanisms  so  that  the  feedback  from  early  applications  can  be  promptly  evaluated 
and  the  required  corrective  actions  initiated  Airing  the  Revision  A  cycle. 

The  Implementation  of  Joint  3LC  and  COQSIA  Issue  resolution  agreements 
during  the  coordination  review  retail  red  a  large  rwmber  of  changes.  The  anguage 
for  these  changes  was  largely  Implemented  by  the  Government  contractor, 
reviewed  by  3LC.  The  development  of  the  last  two  versions  of  the  <*<■*"*"** 
were  driven  by  DMSSO  requested  changes  and  had  no  COCSIA  participation. 

The  development  of  the  three  document  set  versons  prior  to  <*  *•*  •*** 
versions  had  only  limited  CODS1A  review  because  COD5IA  was  acting  y 


advisory  capacity.  These  reviews  were  further  constrained  by  tight  release 
schedules.  Therefore,  with  the  public  release  of  the  documents,  it  is  essential  that 
a  detailed  review  be  conducted  to  validate  the  issues  and  concerns  that  have  been 
agreed  to  by  JLC  and  COOSIA.  This  document  provides  a  baseline  on  the  status 
of  the  specific  Issue  and  concerns. 

One  corporation  corxhjcted  a  detailed  review  of  the  January  30,  1983  version 
of  the  document  and  concluded  that  several  of  the  Issues  considered  closed  by  JLC 
and  COOSIA  task  group  are,  In  fact,  not  yet  fully  closed.  The  specific  issues 
Involved  (16,  61,  63)  are  prioritized  as  "resolved  in  principal  but  require 
refinement."  Such  reviews  should  be  continued  so  that  the  necessary  corrective 
action  can  be  taken  through  change  notices  or  Revision  A  to  the  standard. 

D.  SOS  REVISION  A  OVERVCV  AND  IOLESTCNES 

At  the  point  of  Initial  release  of  DOD-STD-2167,  a  number  of  Issues  were 
resolved  on  an  Interim  basis  only  subject  to  further  R&D.  This  section  describes 
the  initial  CODSIA  plans  for  the  Revison  A  as  coordinated  with  3LC/CSM  Subgroup. 
The  SDS  revision  process  Is  envisioned  to  be  an  ongoing  activity  leading  to  future 
revisions. 

^vision  Process  Drivers.  The  development  of  SDS  Revision  A  is  driven  by  the 
following  five  major  sources  of  activities: 

o  Open  issues  from  the  coordination  review  (cycle  3) 

o  Feedback  from  early  field  usage  of  SDS  Package 

o  STARS  program  and  Software  Engineering  Institute  (SE1)  research 
and  development  activities 

o  Ada  technology  and  practice  evolution 

o  Evolution  of  software  engineering  technology  and  Industry  practice. 

The  Revision  A  process  provides  an  interface  to  the  above  five  major  source 
of  activities  and  converts  them  to  the  evolving  set  of  SDS  Issues.  The  Revision  A 
process  consists  of  the  following  four  major  activities 

o  Identification  of  the  issues 

o  Analysis  and  resolution  of  the  Issues 
•  Draft  Revision  A  development  and  coordination 
o  Revision  A  implementation  and  field  feedback 

Revision  A  Milestones.  The  Initial  set  of  major  milestones  for  the  overall 
Revision  A  process  aret 

o  Identification  of  Issues 

o  Initial  Set  of  Issues 

o  Formal  Coordination  Issues 

o  Rev  A  Issues  Easeline 

o  Feedback  from  Field  Use 

O  CODSIA  Issues  Paper 

o  STARS  Program  and  SE1  Requirements  Issue 


Definition  and  Coordination 


o  Analysis  of  Issues 

o  Proposed  Resolution  of  Issues  Received  frcvn  Jul-Dec  S3 
CODS1A  Focal  Points  and  HQ  AFSC  Staff 


o  Analysis  SOW  Prepared  Sept  85 

o  Analysis/Revision  Contract  Awarded  Oct  S3 

o  EIA  St.  Louis  Issues  Workshop  14-20  Sep  S3 

o  Analysis  Completed  Mar  84 

Coordination/Implementation  of  Revision  A 

o  Preliminary  Draft  3un  86 

o  Review/Coordination  Dec  86 

o  Implementation  June  87 


Revision  A^  Objectives  and  Coals.  The  specific  goals  of  the  Revision  A 
process  are: 

o  To  validate  the  detailed  Implementation  of  Issues  considered  to 

have  been  dosed  in  the  Initial  release  of  the  SDS  Package. 

o  To  close  off  the  open  issues  remaining  from  the  coordination 

review  cycle.  A  manber  of  Issues  are  partially  dosed  while  other 
open  issues  have  been  resolved  based  on  Interim  solutions  only. 

o  To  provide  feedback  from  early  field  usage  of  the  SDS  Package  and 
Implement  corrective  action  through  change  notices.  Revision  A  and 
Handbook  changes. 

o  To  incorporate  early  RAD  products  from  Wte  STARS  program  and 
the  SEI.  Provide  STARS  program  direction  for  SDS  areas  requiring 


In  addition  to  the  above  specific  goals,  the  Revision  A  process  is  guided  by 
the  following  broad  objectives 

o  Provide  technological  currency  of  SDS 

o  Accelerate  software  technology  transition 

o  Improve  software  portability 

o  Encourage  eoftamre  productivity  and  automation 

•  Support  Ada  Introduction 

o  Encourage  production  of  quality  software 

o  Encourage  software  reuse 

•  Improve  peat-deployment  support  and  reduce  life  ■cycle  coats 

•  Provide  flexibility  for  developer  innovations 

o  Minimize  constraints  of  acquisiton  process  on  contractor's  internal 
processes  while  enforcing  aou>d  discipline. 


E.  SUMMARY  OF  OPEN  ISSUES 

During  the  SOS  Package  evolution,  a  total  of  33  issues  were  Idrntifled.  At 
the  completion  of  the  coordination  review  cycle,  29  of  these  issues  are  closed 
while  IS  are  open.  Practically  all  of  the  open  issues  are  partiallv  resolved  or  have 
been  resolved  based  on  Interim  solutions.  During  the  joint  JLC/CSM  and  COSDIA 
Task  Croup  meeting  on  June  7,  1913  the  following  summary  status  and  COD51A 
reprioritization  of  open  issues  was  documented! 


o  Primary  Issues  Requiring  RAD  * 

o  Primary  Issues  -  Resolved  in  principle  but 

require  refinement  3 

o  Other  Primary  Issues  2 

o  Secondary  Issues  9 

o  Tertiary  (sues  _5 

o  Total  Open  Issues  IS 

o  Resolved  Issues  29 

o  Issues  Requiring  Covt/Ind  Action  9 

o  Remapped  Issues  * 

o  Grand  Total  33 


The  following  four  primary  issues  (including  3  issues  consolidated  into  system 
engineering)  retire  considerable  RAD  efforts 

o  Issues  6,10,29,39s  System  Engineering 

o  Issue  7t  Ada  Compatibility 

-  Coding  Standard 

-  DID  Tailoring 

o  Issue  Si  Firmware 

o  Issue  23i  Tailoring  Appendix 

The  following  two  new  primary  issues  are  considered  opera 

o  Issue  39t  MIL-STD-990  Bl/CI  CDS  compatibility  revision) 

o  Issue  33:  Excessive  data 

The  following  three  primary  Issues  are  completely  resolved  In  principle,  but 
retire  considerable  refinement! 

o  Issues  16,17,13,21!  Informal  Testing 

o  Issue  91:  SCF  -  Croup 

o  Issue  93i  SDS  Encourage  Automation 

The  following  four  primary  issues  relate  to  the  SDS  development  process  and 

not  the  SDS  prottoct.  These  issues  are  considered  doaed  as  long  as  the  planned 
SDS  development  process  Is  moving  forward: 

o  Issue  9i  Implementation 

o  Issue  27*  Revision  Strategy 

o  Issue  96i  DIDs  to  be  Superceded 

o  Issue  97i  Training 

The  following  four  open  Issues  are  categorized  as  secondary! 
o  Issue  2:  Relationship  to  2163  (Rewrite  3.3) 


O  Issue  1 3t  New  Methodologies 

o  Issue  M»  fragmentation  of  Mgjn  t  Plans 

o  Issue  tit  DID  Collapsing 

The  following  five  open  Issues  are  categorized  as  tertiary) 

e  Issue  Jt  Supportabllity 

o  Issue  3i  Evolutionary  Acquisition 

o  Issue  lit  SDS  Discussion  of  Personnel  Subsystem 
o  Issue  30«  Editorial 

o  Issue  Si:  Unclear 

P.  NEW  REVISION  A  VtTTlATEO  ISSUES 

As  a  result  of  EIA  Computer  Resources  Workshop*  on  DOD-STD-2147 
contacted  In  St.  Louis,  MO.,  14-20  September,  1913,  an  approach  to  Artificial 
Intelligence/Expert  Systems  (Al/ES)  in  tat  DOD-STD-2147  acquisition  environment  Is 
recommended.  The  approach  proposed  by  the  EIA  workshop  Is  to  handle  Al/ES  es  a 
new  category  of  software  within  the  DOD-STD-2147  tailoring  concept.  To  address 
this  proposed  new  category  of  software  five  new  issues  are  proposed. 

1.  Al/ES  Technical  Development  Methodologies  are  inconsistent  with 
DOD-STD-2147  (Issue  34). 

2.  Al/ES  Life  Cycle  Varies  from  T  radii  tonal  (Issue  37). 

3.  DOD-STD-2147  Documentation  la  Insufficient  for  Al/ES  Systems 
(Issue  31). 

b.  New  Al/ES  Optimised  Lila  Cycle  Management  Methods  are  required 
(Issue  39). 

3.  Other  Al/ES  Unique  Issues  (Issue  40). 

No  Al/ES  comments  or  concerns  were  received  during  the  three  DOD-STD-5DS 
review  cycles.  Based  on  lack  of  comments.  It  was  felt  that  Vie  Al/ES  technology 
practice  was  not  sufficiently  mature  to  initiate  guidance  or  standardization  cr  that 
the  volume  of  business  is  insufficient  to  be  of  concern  for  DOD-5TD-2167  injtiai 
release. 

This  assessment  was  changed  as  a  result  of  the  excellent  work  done  by  panel 
2  of  the  EIA  Computer  Resources  Workshop  In  St.  Louis  under  the  co-chairmanship 
of  Messrs.  R.M.  Bond  of  ARINC.  C.  Wlgle  of  Boeing  Aerospace  and  D.  Preston  of 
1TTR1. 

The  early  conclusions  of  the  workshop  panel  2  are  as  follows) 
o  2147  Is  tallorable  for  Al/ES 

o  Al/ES  has  potentially  serious  Impacts  on  DOD-STD-2147 
documentation 

The  primary  drivers  for  Al/ES  Incompatibilities  erith  the  initial  release  of 
DOD-STD-2147  are  as  follows) 

o  A1  Development  Methodologies 

-  Exploratory  Programming 


-  Bottom-up 

-  Non-Hierarchical 

o  Knowledge  Engineering  not  Addressed  by  DOD-5TD-216? 
o  Al  Applied  to  Fuzzy  Problems 

o  Executable  Data/Self-Modifying  Systems 


SECTION  5.  SUMMARY 


This  section  provides  a  summary  of  the  paper  including  assessment  of  the  SDS 
Package,  acknowledgements,  conclusions  and  recommendations. 

A.  ASSESSMENT  OF  SDS  PACKAGE 

The  release  of  DOD-STD-2167  to  DoO-wide  usage  represents  a  significant 
accomplishment.  Most  of  the  objectives  and  goals  set  for  the  DOD-STD-2167  by 
the  DoO  and  industry  have  been  met.  Work  is  continuing  to  improve  the  standard 
where  issues  are  still  outstanding  or  where  technology  is  driving  future  changes. 
Field  experience  within  the  DoO  and  defense  industry  and  voluntary  usage  outside 
the  DoO  will  provide  the  final  evidence  of  its  success. 

To  provide  a  more  detailed  assessment  of  the  DOD-STD-2167  (initial  release), 
the  following  criteria  are  applied: 

1.  3LC  SDS  objectives 

2.  3LC/CODSIA  issues  criteria 

3.  ElA/AIA  White  Paper  criteria*® 

6.  DODD  6120.21  Acquisition  Streamlining  Directive  criteria** 

3.  General  Standards  Value  criteria*^ 

1.  3LC  SDS  OBJECTIVES 

3LC  SOS  objectives  are  summarized  belowt 

Produce  a  complete,  comistent  tri-service  set  of  acquisition,  development  and 
support  standards  whichi 

o  Establish  a  well-defined  and  easily  understood  software  acquisition 
and  development  process 

o  Provide  adequate  visibility  during  software  development  and 
acquisition 

o  Reduce  confusion  and  eliminate  conflicts  in  existing  standards 
o  Are  compatible  with  modern  methods  of  developing  software 
o  Provide  cast  benefits  over  the  entire  life  cycle 
o  Increase  probability  of  obtaining  quality  software 

The  first  three  objectives  are  completed  with  the  initial  release  of  the 
standard.  The  full  attainment  of  the  last  three  objectives  are  subject  to  SDS 
implementation.  Revision  A  and  the  assessment  of  field  feedback  from  early 
applications. 

2.  3LC/COPSIA  ISSUES  CRITERIA 

The  assessment  of  the  Initial  release  agsinst  the  3LC/CODSIA  issues  criteria 
Is  summarized  in  Section  6.  All  33  issues  hsve  been  dosed  or  have  interim 
solutions  contained  in  the  6  3une  1313  SDS  package.  Eighteen  issues  are  still  open 


for  refinements  and  improvements  during  the  Revision  A  process.  Four  issues 
require  continued  action  by  2LC/CSM  Subgroup  during  DOD-5TD-2167 
implementation: 


o  Issue  9:  SDS  Implementation 

o  Issue  27:  Revision  strategy 

o  Issue  96:  DID*  to  be  superceded 

o  Issue  97s  Training 

All  four  actions  have  been  initiated,  and  as  long  as  they  are  continuing,  they  are 
considered  closed. 

3.  E1A/A1A  WHITE  PAPER  CRITERIA 

The  EIA/AIA  White  Paper  criteria  are  summarized  below: 

o  Sound  Discipline  Without  Inhibiting  Effective  Design 

o  Flexible  Standard  to  Accommodate  Software  of  Differing  Scope  and 
Applications 

o  Development  and  Management  Methodology  Must  Accommodate 
Continuing  Technology  Advances  Without  Loss  of  Discipline 

o  Provide  Clear  Definition  of  Poet-Delivery  Support  Requirements 

o  Careful  Integration  of  Diverse  and  Conflicting  Factors 

Each  of  the  above  criteria  has  a  number  of  sub-criteria.*®  A  review  of  the 
subcriteria  indicates  that  alt  of  them  have  been  mapped  into  the  35  3LC/CSM 
issues  and  that  ail  of  these  are  closed  or  have  action  items  planned  during  Revision 


•.  DODD  9120.21  ACQUISITION  STREAMLINING  DIRECTIVE  CRITERIA 

The  nine  criteria  contained  in  DODD  9120.21  directive**  which  apply  to  DOD- 
STD-2167  are  listed  in  Table  1-9.  The  initial  release  of  the  standard  is  fully 
responsive  to  these  criteria,  with  activities  continuing  during  implementation  and 
Revision  A  phases. 

3.  Standards  Value  Criteria 


The  broadly  quoted  standards  value  criteria**  is  listed  below: 

o  Standards  should  Educate 

o  Standards  should  Simplify 

o  Standards  should  Conserve 

o  Standards  are  a  base  to  Certify  Against 

The  DOO-STD-21 67*  and  its  implementation  plans  are  responsive  to  all  four 
criteria  listed  above. 


TABLE  9-1 


STREAMLINING  INITIATIVE  CRITERIA  (DODD  » 1 20.21) 


Criteria  Supported  By 

- 1 

Initiative  Criteria 

■SETH 

KOI 

CaSHSI 

SDS 

Implementation 

1.  System-Level  Functional 
Requirements 

N/A 

X 

X 

X 

2.  Cut  Off  Referenced 

Documents 

i 

X 

N/A 

N/A 

3.  Reusable  Products  & 

Baseline 

N/A 

X 

x  (STARS 

X 

9.  Require  Tailoring  of 

Stds  &  DIDs 

i 

X 

X 

X 

9.  Design  Trades  &  Risk / 

Cost  Management 

N/A 

X 

X 

N/A 

6.  Specify  "What", 
not  "How  To" 

N/A 

X 

N/A 

X 

7.  AMSDL  &  DODISS  STDs  & 
DIDs  Only 

X 

X 

N/A 

N/A 

1.  DIDs  Consistent  With 

Task  Requirements 

N/A 

X 

X 

N/A 

9.  Only  Required  Data 

Ordered 

N/A 

N/A 

X 

N/A 

Notesi  N/A  -  Not  Applicable!  *  *  Criteria  Satisfied 
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result  of  the  IDA  adopted  by  the  3LC/SDM  Subgroup  chairman  Capt.  Lee  Cooper. 
The  contributions  made  by  Capt.  Cooper  In  the  establishment  of  a  framework  of 
cooperation  between  the  DoO  and  Industry  are  absolutely  critical  to  the  st*cessful 
results  produced  and  the  continuing  evolution  of  the  standards  package. 

Further  acknowledgements  are  due  tot 

o  3LC/CSM  Subgroup  members  and  past  and  present  Chairmen  Lt. 

Col.  Oberkrom,  Lt.  Col.  Casper  Klucas,  Major  Larry  Fry,  Lt.  Cdr. 

M  i '< e  C  *M  '.nr!  '.**  r  . 


350 


°  JLC  and  E1A  workshop  participants  and  their  sponsoring 
organizations. 

o  Industry  and  DOO  reviewers  and  their  organizational  sponsors. 

o  Industry  issue  coordinators,  special  working  groups  and  their 
organizational  sponsors. 
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C.  CONCLUSIONS 

The  most  significant  Conclusion*  related  I  to  the  SDS  product  are: 

1.  The  quality  of  the  SDS  Package,  as  measured  by  issues  resolved,  is 
directly  related  to  the  voluntary  effort  put  forth  by  industry  and 
the  DoO. 

2.  The  SDS  Package  Is  a  significant  accomplishment  and  meets  most 
of  the  criteria  established  by  the  DoO  and  industry: 

o  JLC  SOS  objectives 

o  JLC/DODSIA  issues  criteria 

o  EIA/AIA  white  paper  criteria 

o  DODD  #120.2  Acquisition  Streamlining  Directive  criteria 

o  General  standard#  value  criteria 

Further,  work  is  continuing  for  improvements  against  the 
above  listed  criteria  where  not  yet  fully  met. 

3.  SDS  Package  provides  a  standards  foundation  for  technology 

insertion  from  the  other  DoO  software  initiatives  Ada,  STARS  and 

SEi,  as  well  as  the  private  sector  technology  developments. 

%.  The  accomplishment  of  a  single  software  development  standard  is 

not  without  risks.  The  range  of  computer  programs  to  be  covered 

by  DOD-STD-2167  is  extremely  broad.  Tailoring  of  the  standard  is 
absolutely  essential  if  the  flexibility  for  spanning  the  wide  range  of 
defense  systems  and  the  variations  in  project  size  and  software 
categories  is  to  be  achieved. 
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The  most  significant  conclusions  related  to  the  SDS  Package  develooment 
process  are:  ^ 


The  IDA  represents  a  significant  change  from  the  conventional 
defense  standards  development  process  and  was  critical  to  the 
qjality  of  the  DOD-5TD-2167  and  its  acceptance  by  the  industry. 


The  IDA  can  serve  as  a  model  for  the  development  of  future 
standards  in  the  MCCR  area. 


3.  3LC/CRM  commitment  to  the  Revision  A  process  and  SDS 
implementation  plans  was  essential  for  industry  endorsement  of  the 
initial  release  of  DOD-STD-2167. 


RECOMMENDATIONS 


The  following  are  the  most  significant  recommendations: 


Industry  and  DOD  should  provide  adequate  resources  to  complete 
the  planned  Revision  A  process  by  June  1317.  The  issue  resoli*. 
tions  should  be  completed  by  June  1916. 


Industry  and  DoD  volunteers  should  establish  3LC/CODSIA 
coordinated  working  groups  to  address  each  of  the  Revision  A  open 
issues. 


Industry  associations  and  DoD  organizations  should  consider 
sponsoring  JLC/CODS1A  coordinated  Joint  DoD  and  industry 
workshops  to  address  the  following  seven  major  Revision  A  issues: 

o  Automation 


o  Methodology 
o  Reusable  Software 
o  Ada 


System  engineering 
AI/ES 


o  Firmware 


Industry  and  DOD  should  refine  the  IDA  for  Revision  A  and  use  it 
as  a  model  for  the  development  of  future  standards  In  the  MCCR 
area. 


The  coordination  and  technology  transfer  between  the  JLC  SDS 
software  Initiative  and  the  other  DcO  software  Initiatives:  Ada, 
STARS  and  SE!  dould  be  Improved. 

DMSSO  should  consider  developing  data  bases,  tools  and  network 
access  for  the  automated  processing  of  public  review  com  menu. 

Industry  and  DoD  should  support  the  proposed  DOD-3TD-2U7 
Implementation  plana  so  that  the  full  benefits  of  the  SDS  Package 
can  be  achieved  in  a  timely  manner. 

Individuals  Interested  in  perticlpating  In  working  groups  and 
organizations  considering  sponsoring  DOO-STD*2U7  Revision  A  Issue 
resolution  activities  should  contact  the  following: 


DOD: 


AIAi 


Capt.  Rick  Butler  or 
Capt.  Lee  Cooper 
Andrews  AFB,  MO  2033% 
(301)  911-3731/* 

AV  131-5731/% 

ElAi  Mr.  Ole  Golubjatnikov 

General  Electric  Co. 

FRP  1,  Room  D6 
Syracuse,  NY 
(313)  %34-*7%% 
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Mr.  Austin  Maher 
Singer  Kearfott  Corp. 
130  Totowa  Rd 
Wayne,  N3  07*70 
(201)  713-4407 

NSlAt  Mr.  Sim  Heil 
ITT  Avionics 
100  Kingsland  Road 
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(201)  21*-29*4 
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